m 



HEWLETT 
PACKARD 



HEWLETT-PACKARD COMPANY 
LOGIC SYSTEMS DIVISION 



HP 64000 

Logic Development 

System 



SYSTEM RELEASE BULLETIN 



Part Number: 5958-6019 Printed: OCTOBER 1988 

E1088 



*********************************************************************** 



* 

* 



* 
* 
* 
* 



* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 



HP STARS II 



64000 SOFTWARE RELEASE BULLETIN 



* 
* 



OCTOBER, 1 988 



* 
* 
* 
* 
* 
* 
* 
* 
* 
* 



* 
* 



* 
* 
* 
* 



* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 



UPDATE 88. 10A * 



* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 



* This document supersedes all previously dated SSBs. * 

* * 

* * 

* * 

* * 

* * 

* * 

* * 

* * 

* * 

* * 

* * 

* HEWLETT * 

* PACKARD * 

* * 
*********************************************************************** 



*********************************************************************** 
* NOTICE * 



* 



* 



* The information contained in this document is subject to change without notice. * 

* * 

* HEWLETT-PACKARD MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS * 

* MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF * 

* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not * 

* be liable for errors contained herein or for incidental or consequential damages in connection with the * 

* furnishing, performance or use of this material. * 

* * 

* Hewlett-Packard assumes no responsibility for the use or reliability of its software on equipment that * 

* is not furnished by Hewlett-Pacf *rd. * 

* * 

* This document contains proprietary information which is protected by copyright. All rights are * 

* reserved. No part of this document may be photocopied, reproduced or translated to another language * 

* without the prior written consent of Hewlett-Packard Company. * 

* * 

* * 

* * 

*********************************************************************** 

Copyright (c) 1983 by HEWLETT-PACKARD Company 



READER COMMENT SHEET 
STARS II SRB (STARS B) 
Issue . DATE / /_ 



We welcome your evaluation of this bulletin. Your comments and suggestions help us to improve our publications. 
Please use additional pages if necessary. 

Is this bulletin technically accurate? Yes [ ] No [ ] (If no, explain under Comments, below.) 

Are the concepts and wording easy to Yes [ ] No [ ] (If no, explain under Comments, below.) 

understand? 

Is the format of this bulletin convenient in size, Yes [ ] No [ ] (If no, explain or suggest improvements under 
arrangement and readability? Comments, below.) 

Comments: 



************************************************************************** 

Date: 

FROM: 

Name 

Company 

Address 



STARS B 

Printed in U.S.A. 



FOLD 



FOLD 



II 



NO POSTAGE 

NECESSARY 

IF MAILED 

IN THE 

UNITED STATES 



BUSINESS REPLY MAIL 

FIRST CLASS PERMIT NO. 1303 COLORADO SPRINGS, CO. 
POSTAGE WILL BE PAID BY ADDRESSEE 



STARS Administration 

Hewlett-Packard Company 

Logic Systems Division 

P.O. BOX 617 

Colorado Springs, Colorado 80901-0617 



FOLD 



FOLD 



PREFACE 



This Software Release Bulletin documents all fixes and enhancements that 
are incorporated in the new release identified on the cover page. The 
SRB is provided as a benefit of Hewlett-Packard's Account Management 
Support, Response Center Support, and Software Materials Subscription. 

Of the five sections contained in the SRB (not including the PREFACE), 
only the last section which contains the detailed reports has page num- 
bers. These are referenced by the product, report number and keyword 
indexes in order to direct the user to a particular area or to an in- 
dividual detailed report. The five sections are described below. 

SOFTWARE RELEASE CONTENTS 

This section lists the product names, numbers and update/fix levels of 
all products contained in this release. Products that have changed, or 
are new are denoted with an asterisk preceding the product name. 

PRODUCT INDEX 

Each unique product name/number has an entry listing the page number 
where the detailed report for that product begins . 

REPORT NUMBER INDEX 

This index is a sequential list of the individual report numbers with 
the corresponding page number where the report can be found. 

KEYWORD INDEX 

This index is sorted by product name, keyword, product number (including 
the update/fix level) and by report number in that order. In addition 
to the sort items, each entry has a brief description (one line) and the 
page number where the detailed report can be found. Note that a given 
report can be listed more than once in this section if it has more than 
one keyword assigned to it. 

DETAILED REPORTS 

Each report contains all the available information relevant to the 
problem being corrected or the enhancement being implemented. 



Software release contents 



Product name 


Product number 


uu.ff 


*6U0OO-UX OP-ENV 


300 6U801S00U 


01.80 


*6800 C 


6U821 


02.10 


*6800 C 


300 6H821S001* 


02.10 


*6800 C 


500 6U821S001 


02.10 


*6800 C 


VAX 6U821S003 


02.10 


*680O PASCAL 


6U811 


01.90 


# 6800 PASCAL 


300 6U8IISOOI4 


01.90 


*6800 PASCAL 


500 6U811S001 


01.90 


*6800 PASCAL 


VAX 61+811S003 


01.90 


*6800O ASSEMB 


6U8U5 


02.10 


*68000 ASSEMB 


300 6U8I45SOOU 


02.10 


*68000 ASSEMB 


500 6U8U5S001 


02.10 


*680OO ASSEMB 


VAX 6U8U5S003 


02.10 


*68ooo c 


6U819 


02.10 


*68000 C 


300 6l*8l9S00l* 


02.10 


*6800O C 


500 61+819S001 


02.10 


*68000 C 


VAX 6U819S003 


02.10 


*68000 PASCAL 


6U815 


01.90 


*68000 PASCAL 


300 6U815S00U 


01.90 


*68000 PASCAL 


500 6U815S001 


01.90 


*68000 PASCAL 


VAX 6U815S003 


01.90 


*68000C AXLS COMF 


' 300 6U902S001+ 


01.00 


*6809 C 


6U822 


01.80 


*6809 C 


300 6U822S00U 


01.80 


*6809 C 


500 6U822S001 


01.80 


*6809 C 


VAX 6U822S003 


01.80 


*6809 PASCAL 


61*813 


01.60 


*6809 PASCAL 


300 61+813S00U 


01.60 


*6809 PASCAL 


500 6U813S001 


01.60 


*6809 PASCAL 


VAX 6U813S003 


01.60 


* 78310/12 ASSEMB 


6U866 


01.02 


*80286B ASSEMB 


6I+859 


01.30 


*80286B ASSEMB 


300 6U859SOOI4 


01.30 


# 80286B ASSEMB 


500 6U859SOOI 


01.30 


*80286B ASSEMB 


VAX 6U859S003 


01.30 


*8085 B PASCAL 


6U825 


01.90 


*8085 B PASCAL 


300 6U825S001* 


01.90 


*8085 B PASCAL 


500 6U825S001 


01.90 


*8085 B PASCAL 


VAX 6U825S003 


01.90 


*8085 C 


6U826 


02.10 


*8085 C 


300 61+826S00U 


02.10 


*8085 C 


500 6U826S001 


02.10 


*8085 C 


VAX 6U826S003 


02.10 


*8085 EMULATION 


61*203 


01.07 


*8086/8 ASSEMB 


6U853 


02.70 


*8086/8 ASSEMB 


300 6U853S00U 


02.70 


*8086/8 ASSEMB 


500 6U853S001 


02.70 


*8086/8 ASSEMB 


VAX 61+853S003 


02.70 


*8086/8 C 


61*818 


03.70 


*8086/8 C 


300 6U818S00U 


03.70 


*8086/8 C 


500 6U818S001 


03.70 


*8o86/8 C 


VAX 6U818S003 


03.70 


* 8086/8 PASCAL 


6U81U 


03.50 


*8o86/8 PASCAL 


300 61*8ll*S00l* 


03.50 


*8o86/8 PASCAL 


500 6U81US001 


03.50 



Software release contents 



Product name 




Product number 


uu.ff 


*8086/8 PASCAL 


VAX 


6U81US003 


03.50 


*9900/0 ASSEMB 




6U8147 


01.80 


*9900/0 ASSEMB 


300 6U8>47SOOlt 


01.80 


*9900/0 ASSEMB 


500 


6U8147S001 


01.80 


*9900/0 ASSEMB 


VAX 


6U8U7S003 


01.80 


*F9U50 EMULATION 




6U286 


01.05 


*HOST SOFTWARE / 


VAX 


6U882 


02.30 


*HOST SOFTWARE / 


300 


6I4883 


01.10 


*HOST SOFTWARE / 


500 


6U880 


01.80 


*MS1750A ASSEMB 




6U857 


01.90 


*MS1750A ASSEMB 


300 


6i4857SOOU 


01.90 


*MS1750A ASSEMB 


500 6>4857S001 


01.90 


*MS1750A ASSEMB 


VAX 


6U857S003 


01.90 


*OPERATING SYSTEM 




6U100 


02.10 


*RS-232 TRANSFER 


300 6U885 


01.30 


*RS-232 TRANSFER 


500 


6U88U 


01.30 


*RS-232 TRANSFER 


VAX 


6HQQ6 


01.50 


*TMS 32010 MODULES 


6U285 


01.02 


*USER DEF ASSEMB 


300 


6U851S001* 


02.10 


*USER DEF ASSEMB 


300 


61+861S001* 


02.10 


*USER DEF ASSEMB 


500 6I485ISOOI 


02.10 


*USER DEF ASSEMB 


500 


6U861S001 


02.10 


*USER DEF ASSEMB 


VAX 


6U85ISOO3 


02.10 


*USER DEF ASSEMB 


VAX 


6U861S003 


02.10 


*USER DEF EMULATION 


61+27*4 


01.06 


*USER INTERFACE 


300 


6U808S001* 


02.10 


*USER INTERFACE 


500 


6I4808SOOI 


02.10 


*Z80/NSC800 C 




6U82U 


02.10 


*Z80/NSC800 C 


300 


6U82US00H 


02.10 


*Z80/NSC800 C 


500 


6U82US001 


02.10 


*Z80/NSC800 C 


VAX 


6*482US003 


02.10 


*Z80/NSC800PASCAL 




6U823 


01.90 


*Z80/NSC800PASCAL 


300 


6U823S00U 


01.90 


*Z80/NSC800PASCAL 


500 


6U823S001 


01.90 


*Z80/NSC800PASCAL 


VAX 


6I4823SOO3 


01.90 


*Z8000 C 




6U820 


02.10 


*Z8000 C 


300 


6i+820S00l* 


02.10 


*Z8000 C 


500 


6U820S001 


02.10 


*Z8000 c 


VAX 


6U820S003 


02.10 


*Z8000 PASCAL 




6U8l6 


01.90 


*Z8000 PASCAL 


300 


6U816S00H 


01.90 


*Z8000 PASCAL 


500 


6U816S001 


01.90 


*Z8000 PASCAL 


VAX 


6U816S003 


01.90 


*Z8002 EMULATION 




6U233 


02.01 



Product index 



Product name 



Product number 



Page 



61+000-UX OP-ENV 300 
6800 C 
6800 PASCAL 
68000 ASSEMB 
68000 C 
68000 PASCAL 
6809 C 
6809 PASCAL 
80286B ASSEMB 
8085 B PASCAL 

8085 C 

8085 EMULATION 
8086/8 ASSEMB 
8086/8 ASSEMB 300 
8086/8 ASSEMB VAX 
8086/8 C 

8086/8 c 300 
8086/8 c 500 
8086/8 PASCAL 
9900/0 ASSEMB 
F9U5O EMULATION 
HOST SOFTWARE / VAX 
HOST SOFTWARE / 300 
HOST SOFTWARE / 500 
MS1750A ASSEMB 
OPERATING SYSTEM 
TMS 32010 MODULES 
USER DEF ASSEMB 500 
USER DEF ASSEMB VAX 
USER DEF EMULATION 
USER INTERFACE 300 
Z80/NSC800 C 
Z80/NSC800 c 300 
Z80/NSC800PASCAL 
Z80/NSC800PASCAL VAX 
Z8000 C 
Z8000 PASCAL 
Z8002 EMULATION 



6U801S00U 

614821 

6U811 

6U8U5 

6I4819 

6i+8l5 

6U822 

6U813 

6U859 

6U825 

6U826 

61+203 

6U853 

6U853SOOU 

6U853SOO3 

61+818 

6W18S00U 

6U818S001 

6U81U 

6U8kJ 

6U286 

6U882 

6U883 

6U880 

6U857 

6U100 

6U285 

6U85ISOOI 

6U85ISOO3 

6U27U 

6U808SOOU 

6k82k 

6U82US001+ 

6U823 

6i+823S003 

61+820 

6U816 

6U233 



1 

8 

lk 

19 
20 
26 
31 

3h 
38 
39 
1+3 
U9 
50 
55 
56 
57 
83 
8k 

85 
106 
108 
110 
111 
112 
llU 
115 
119 
120 
121 
122 
12U 
127 
135 
136 
1*48 

1*49 
152 
156 



Report number index 



Report # 


page 


Report # 


page 


Report # 


page 


Report # 


page 


165000U598 


50 


5OOOI7065U 


127 


D200007179 


28 


D200071**15 


157 


165OO0U705 


85 


500017112*4 


20 


D20001*43*40 


23 


D200071**23 


1*43 


1650006908 


115 


5000171876 


90 


D200015073 


9 


D2O0071*431 


131 


165OO08U09 


8 


500017188*4 


90 


D2000153*47 


9 


D200072371 


77 


1650009^56 


26 


5000171900 


91 


D200019265 


113 


D200073031 


1*4*4 


1650011585 


136 


5000172239 


65 


D200019273 


93 


D20007*4237 


78 


1650013235 


50 


5000172593 


51 


D200022137 


93 


D2OO0750*4*4 


131 


1650018689 


85 


50001727*42 


U3 


D200023283 


93 


D200075861 


15 


1650018721 


112 


5000172825 


127 


D200025858 


72 


D2000759H 


31* 


165001922U 


26 


5000173278 


128 


D200027953 


117 


D200075952 


101 


1650019257 


110 


5000181552 


116 


D200031**76 


73 


D200076026 


152 


1650019331 


27 


500018201*4 


138 


D200035220 


106 


D200076067 


1*45 


1650026583 


20 


5000185066 


1 


D200038778 


130 


D200076109 


*40 


1650026708 


57 


5000186718 


66 


D2000*42606 


73 


D200076588 


2 


1650033209 


115 


50001867*42 


138 


D2000*43828 


123 


D200076620 


2 


1650036525 


12*4 


5000188839 


21 


D2000146623 


123 


D200076679 


3 


1650038281 


1 


5000189985 


116 


D2000149916 


7*4 


D200076760 


1*49 


1650038U30 


83 


5000190629 


139 


D200053710 


9*4 


D200076802 


11 


1650038521 


12U 


5000193*466 


66 


D200057802 


7*4 


D2OO0768*4*4 


31 


2700005520 


57 


5000195628 


68 


D200060509 


52 


D200076919 


*45 


5000103^32 


86 


500019762*4 


91 


D200061556 


19 


D200077008 


3 


5000111666 


115 


5000201012 


51 


D20006260*4 


117 


D200077065 


2*4 


50001l68»48 


1*4 


50002017*49 


69 


D200063123 


1*4 


D200077107 


1*49 


50001188*4*4 


86 


5000202770 


116 


D2O0063719 


3*4 


D2000771*49 


11 


5000121830 


106 


50002028146 


**3 


D200063750 


95 


D20007718O 


31 


500012*013 


87 


5000203596 


70 


D200063792 


28 


D200077222 


132 


500013^593 


58 


50002014586 


22 


D20006383** 


152 


D200077263 


U6 


500013^601 


58 


50002066*49 


22 


D200063875 


1*40 


D200077396 


80 


500013^817 


88 


50002078*45 


91 


D200063909 


39 


D2OO077*495 


12*4 


5000136085 


50 


5000216036 


70 


D20006U212 


39 


D200077727 


80 


5000136267 


59 


5000217927 


139 


D200065060 


95 


D200077768 


52 


5000137869 


156 


500021920*4 


112 


D200066357 


109 


D200077875 


102 


5000138388 


88 


5000220186 


*43 


D200066761 


1*40 


D2000779*4l 


3 


50001149229 


60 


5000221788 


8*4 


D200067629 


10 


D200077958 


*4 


50001U9757 


61 


500022199*4 


92 


D200068*403 


*4*4 


D2000786U2 


102 


50001U9765 


62 


5000223099 


23 


D20006868*4 


75 


D200078923 


7 


5000151^31 


156 


5000223792 


119 


D200068759 


97 


D200079038 


5 


5000152918 


U 9 


5000223800 


71 


D200068767 


99 


D200079079 


132 


5000161000 


136 


500022*4022 


108 


D200068825 


38 


D200079087 


U6 


5000l6l03*4 


137 


500022*420*4 


1*48 


D200068957 


109 


D200079095 


5 


50001621+87 


63 


5000226605 


135 


D20006910*4 


110 


D2000791H 


81 


5000163287 


137 


5000226613 


55 


D200069666 


2*4 


D200079129 


25 


5000163^10 


6*4 


5000229*476 


72 


D200070532 


75 


D200079137 


1*49 


5000l6382i+ 


89 


5000231605 


128 


D200070615 


76 


D2000791**5 


11 


500016*400*4 


108 


5000232959 


106 


D200071332 


1*41 


D200079152 


31 


500016513*+ 


6*4 


5000233866 


129 


D2000713**0 


1*42 


D200079160 


*47 


5000169*47*4 


1 


500023*4237 


23 


D200071365 


1*42 


D200079178 


16 


5000170*415 


51 


50002*41562 


122 


D200071373 


130 


D200079186 


35 



Report number index 



Report # 


page 


Report # 


page 


Report # 


page 


Report # 


page 


020007919*4 


10U 


D200079293 


5 


02000803^1 


150 


D200081638 


121 


D200079202 


29 


D200079301 


lU6 


D200080358 


12 


D20008198U 


6 


D200079210 


153 


D200079335 


56 


D200080366 


32 


D200082636 


111 


D200079228 


1*1 


D200079509 


6 


D200080371+ 


133 


D200082669 


110 


D200079236 


17 


D200080051 


82 


D200080382 


1*7 


D200085050 


118 


D2000792l*U 


36 


D2O0080093 


6 


D200080721 


125 


D2000933M 


19 


D200079251 


105 


D200080101 


7 


D2000811H1 


125 


D200093369 


107 


D200079269 


30 


D200080135 


125 


D200081U71 


133 


D200093377 


53 


D200079277 


15^ 


D200080333 


82 


D200081620 


120 


D200093393 


111* 


D200079285 


U2 















Keyword index 



Keyword 



-4 



Product number uu.ff Description 



********none******** 64801S004 

64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 
64801S004 

ENHANCEMENT 64801S004 



released 
pv to hang 



01.00 No error message given when opt run on memory board. 

01.00 Edbuild does not work whether invoked by the user or the emulator 

01.00 Msinit may autoconf igure incorrectly. 

01.00 HP enhancements are too slow to run softkeys. 

01.50 If second card cage used in pv , it may not be 

01.50 Pressing return during a cycle command causes 

01.50 Msinit crashes opt test user. 

01.50 If /usr/hp64000/lock does not exist, msconfig gives odd messages. 

01.60 pwd truncates the /net/system portion of the path when RFA'ed to system. 

01.60 Search command files via "PATH" variable 

01.60 option test multitest can't handle more than 24 cards 

01.60 EDBUILD IS NOT WORKING PROPERLY 

01.60 Incompatible /etc/update programs. 

01.60 64000-UX processes do not die when modem carrier is lost. 

01.60 Processes sometimes left running after parent has stopped. 

01.70 Multiple <cr> after selecting card will leave softkeyw in an odd state. 

01.60 64000-UX uses TERMINF0 database only partially. 



■8 



Keyword 



Product number uu.ff Description 



********none******** 64821 

64821 
64821 

CODE GENERATOR 64821 

64821 
64821 
64821 

PASS 1 64821 



Report # page 



50001 
50001 
D2000 
D2000 
D2000 
D2000 
D2000 
D2000 
16500 
D2000 
D2000 
D2000 
D2000 
D2000 
D2000 
D2000 
D2000 



69474 
85066 
77941 
77958 
76588 
76620 
76679 
77008 
38281 
78923 
79038 
79095 
79509 
80093 
81984 
79293 
80101 



1 
1 
3 
4 
2 
2 
3 
3 
1 
7 
5 
5 
6 
6 
6 
5 
7 



Report # page 



01.06 Assigning to bitfield causes entire structure to be reset. 

01.07 Array is being placed in the PROG section rather than data. 
01.07 Warning message text is incorrect. 

00.01 Nested IF stmnt. with bit field structure members genrate incorr. code 
01.04 Using a pointer dereference as an array index generates incorrect code. 
01.04 Compiler doesn't reload register after value changes in a nested if expr 
01.07 Floating point division of 2 constants generates incorrect result 
01.07 DIV, MOD and COMParisons may do unsigned estend of signed values 

- -8 



D200067629 
D200076802 
D200080358 
1650008409 
D200015073 
D200015347 
D200077149 
D200079145 



10 

11 

12 

8 

9 

9 

11 

11 



Keyword 



Product number uu.ff Description 



Report # page 



********none******** 64811 

64811 

64811 

PASS 1 64811 

WITH 64811 



01.10 functional type change of a constant into multi-byte structure gen's err D200063123 



01.20 Unsigned_8 treated as signed value in FOR loop test 

01.20 Pascal does not report error for assignment of constant to structure 

01.20 Functional type changes not always evaluated correctly 

01.08 Generates bad code for parameter as ADDR of component. 

- -8 



D200075861 
D200079178 
D200079236 
5000116848 



14 
15 
16 
17 
14 



Keyword 



Product number uu.ff Description 



********none******** 64845 
PROBLEM ON VAX 64845 



01.10 EQU is not working with DC correctly. 

00.00 *PR0DUCT # CHANGE on the VAX* From= 64xxxS003 To=64xxxM003 



-8 



Keyword 



Product number uu.ff Description 



********none******** 64819 

64819 



01.02 68008 libraries cause target processor disagree errors. 
01.09 Result is invalid if terenary expression evaluates to false. 



Report # page 



D200061556 
D200093344 


19 
19 


Report # 


page 


5000234237 
5000171124 


23 
20 



Keyword index 



Keyword 



Product number uu.ff Description 



Report # page 



********none******** 64819 

64819 
64819 
64819 
64819 

CODE GENERATOR 64819 

64819 

ENHANCEMENT 64819 

PASS 1 64819 



01.09 Two external declarations are made for one function. 

01.09 Compiler aborts when it encounters a legal structure declaration. 

01.10 Invalid error 60 flagged. 

01.10 SLIST 0N/0FFS doesn't work correctly. 

01.10 Wrong floating point value assigned in a terenary expression. 

01.07 Bad code using $RANGE$ or $DEBUG$ with $CALL_PC_L0NG$ or $LIB_PC L0NG$ 

01.10 Floating point division of 2 constants generates incorrect resulT 

01.90 Generate XREF from compiler which is readable by EDT . 

01.10 DIV, MOD and COMParisons may do unsigned estend of signed values 



5000206649 
D200069666 
1650026583 
5000188839 
5000204586 
D200014340 
D200077065 
5000223099 
D200079129 



-8 



Keyword 



Product number uu.ff Description 



********none******** 64815 

64815 
64815 
64815 
64815 

PASS 1 64815 

64815 



00.01 System reboot for syntax error. 

01.10 Incorrect code generated for array which has boolean indices. 

01.10 Set manipulation results in incorrect code being generated. 

01.11 functional type change of a constant into multi-byte structure gen's err 

01.12 Pascal does not report error for assignment of constant to structure 
00.00 COMP SYM file not purged when COMP_SYM option not selected. 

01.12 FuncTional type changes not always evaluated correctly 

- -8 



Keyword 



Product number uu.ff Description 



******** none ******** 64822 

64822 
CODE GENERATOR 64822 
PASS 1 64822 



01.08 Array is being placed in the PROG section rather than data. 

01.08 Warning message text is incorrect. 

01.08 Floating point division of 2 constants generates incorrect result 

01.08 DIV, MOD and COMParisons may do unsigned estend of signed values 



- -8 



Keyword 



Product number uu.ff Description 



22 
24 
20 
21 
22 
23 
24 
23 
25 



Report * page 



1650009456 
1650019224 
1650019331 
D200063792 
D200079202 
D200007179 
D200079269 



26 
26 
27 
28 
29 
28 
30 



Report # page 



D200076844 
D200080366 
D200077180 
D200079152 



31 
32 
31 
31 



Report # page 



********none******** 64813 

64813 
64813 

PASS 1 64813 



01.10 functional type change of a constant into multi-byte structure gen's err D200063719 34 

01.11 Unsigned_8 treated as signed value in FOR loop test. D200075911 34 
01.11 Pascal does not report error for assignment of constant to structure D200079186 35 
01.11 Functional type changes not always evaluated correctly D200079244 36 



Keyword Product number 

********none******** 64859 



uu.ff Description Report # page 

01.02 Assembling on 64100 & linking on VAX generates erroneous absolute file D200068825 38 

- -0 



Keyword 



Product number uu.ff Description 



Report # page 



********none******** 64825 

64825 
64825 

PASS 1 64825 



01.03 functional type change of a constant into multi-byte structure gen's err D200063909 39 

01.04 Unsigned_8 treated as signed value in FOR loop test. D200076109 40 
01.04 Pascal does not report error for assignment of constant to structure D200079228 41 
01.04 Functional type changes not always evaluated correctly D200079285 42 



Keyword index 



Keyword 
PASS 2 

Keyword 



Product number 
64825 



uu.ff Description 

01.03 Incorrect code generated when set elements are passed as parameters 

- -0 



Product number uu.ff Description 



Report # page 
D200064212 39 

Report # page 



********none******** 64826 

64826 

fidR9fi 

CODE GENERATOR 64826 

64826 
64826 
64826 
64826 

PASS 1 64826 



Keyword Product number 

********none******** 64203 



01.03 Expression used as array index generates incorrect code. 

01.04 Array is being placed in the PROG section rather than data. 
01.04 Warning message text is incorrect. 

01.03 bad code generated with *pointer++ operation 

01.04 > = does not work with float type 

01.04 When subtract an integer from a pointer, get unnecessary warning message 
01.04 Floating point division of 2 constants generates incorrect result 
01.04 +=, -=, *=, & /= may fail to auto vars with $RECURSIVE 0N$ 
01.04 DIV, MOD and COMParisons may do unsigned estend of signed values 

- -0 
uu.ff Description 

01.06 Can't use 9.5" paper to print mem map, due to centering of printout. 

- -0 



Keyword 



Product number uu.ff Description 



********none******** 64853 

64853 
64853 
64853 
64853 

CODE GENERATOR 64853 

LINKER 64853 

64853 

PROBLEM ON VAX 64853 



02.00 Assembler/linker does not correctly handle EQU <EXT_LABEL> statement 

02.01 Wrong values during EQU from externals. 

02.01 reusing accumulator 

02.03 Tabs in source file are expanded to 6 spaces instead of 8 spaces 
02.03 The noload files aren't showing up in the listing; absolute correct 

02.02 Incorrect Object code generated 

02.01 Linker generates error if C0MN segment is not 0000H 

02.03 Label preceeded with WORD PTR , NEAR PTR , etc. will not appear in the 
00.00 *PR0DUCT # CHANGE on the VAX* From= 64xxxS003 To=64xxxM003 



D200068403 


44 


D200076919 


45 


D200080382 


47 


5000172742 


43 


5000202846 


43 


5000220186 


43 


D200077263 


46 


D200079087 


46 


D200079160 


47 


Report tt 


page 


5000152918 


49 



Report ft page 

5000136085 50 

1650004598 50 

D200077768 52 

1650013235 50 

5000170415 51 

5000201012 51 

D200060509 52 

xref 5000172593 51 

D200093377 53 



Keyword 
LINKER 

Keyword 

CODE GENERATOR 

Keyword 



Product number 
64853S004 

Product number 
64853S003 

Product number 



****#***none******** 64818 

64818 



uu.ff Desc ript ion 

02.20 Linker can generate invalid DATE on listing file. 

- -0 
uu.ff Desc ript ion 

02.50 VMS Hosted linker does not recognize logical names 

- -0 

uu.ff Description 

02.00 Using a postfix decrement operator in a conditional statement fails 
02.00 Compiler uses wrong segment register. 



Report # page 
5000226613 55 

Report # page 
D200079335 56 

Report # page 

D200031476 73 
D200042606 73 



Keyword index 



Keyword 



Product number uu.ff Description 



Report # page 



>fC5tC3#C>4C3tC3tC3#C)4C n n e 3|C3#C3|C $£$) 


K* 64818 




64818 




64818 




64818 




64818 




64818 




64818 


CODE GENERATOR 


64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 




64818 


LINKER 


64818 


PASS 1 


64818 




64818 


RUN-TIME LIBRARY 


64818 


SF1001 


64818 



03. 


00 


03 


01 


03 


02 


03 


02 


03 


02 


03. 


02 


03 


02 


01 


,06 


02 


.01 


02 


.01 


02 


,01 


03 


.00 


03 


.00 


03 


.01 


03 


.01 


03 


.01 


03 


.01 


03 


.01 


03 


.01 


03 


.02 


03 


.02 


03 


.02 


03 


.02 


03 


.02 


03 


.02 


03 


.02 


03 


.20 


03 


.30 


03 


.10 


03 


.02 


03 


.02 


00 


.00 


03 


.02 



DX register is used although it is overwritten by IMUL instruction 

ES reg overwritten when assign char array to complex data structure 

Code generated for illegal C statement - POP BH generated 

Address of array element incorrectly calculated 

external used 2x in same pgm, w/ ASM FILE ON, get 2 EXT stmts in ASMfile 

PROGRAMS WITH DUPLICATE GOTO LABELS MAY FAIL IN PASS 3 

Warning message text is incorrect. 

Argument to switch statement may be doubled. 

1102 error generated - register needed but not availiable 

Incorrect segment of array transfered to pointer 

ES register corrupt when used to get address of array to 

Return statement not putting value on BX register 

Nonsense code generated by dynamic struc declaration in 

Right shift using var. for # of places to shift generate 

Floating point division of 2 constants generates incorre 

When using calculated value for array index, uses BX reg 

Compile incorrect when a ptr to an int is casted as a sh 

Incorrect segment passed to external function 

Assignment to ptr var. (w/ Separate const off) causes co 

Vax not creating same code as the 64~000 

BX register overwritten with a switch statement 

Bad code generated for address of external character if 

Incorrect segment passed to external function 

VAX and 64100 generate different constants. VAX is inco 



place in ptr. 

a f unc t . 

s bad code 

ct result 

ister twice 

ort and incremen 

rrupt stack 



for loop 
rrect . 
symbol table 



CL register being used twice 

Cannot prevent adding Esymbol and Rsymbol info to global 

compiler reusing CX register 

Problem w/ unreleased Rev. Dx Register destroyed 

The noload files aren't showing up in the listing, absoli 

compiler using DS segment rather than ES segment for 32 t 

DIV, MOD and COMParisons may do unsigned estend of signec 

REAL NUMBER COMPARISONS MAY NOT EVALUATE CORRECTLY. 

When casting unsigned ints to floats using += , generates a error #1001 

- -0 



-ute correct 
bit pointers 
;d values 



D2000 
50001 
50001 
50001 
50001 
D2000 
D2000 
D2000 
50001 
50001 
50001 
50001 
D2000 
16500 
50001 
50001 
D2000 
D2000 
D2000 
50001 
50001 
50002 
D2000 
D2000 
D2000 
D2000 
50002 
50002 
50002 
50001 
D2000 
27000 
50002 



49916 
95628 
49757 
49765 
72239 
74237 
80333 
25858 
34593 
34601 
36267 
49229 
57802 
26708 
86718 
93466 
68684 
70615 
72371 
62487 
65134 
23800 
70532 
77396 
77727 
80051 
01749 
03596 
16036 
63410 
79111 
05520 
29476 



74 
68 
61 
62 
65 
78 
82 
72 
58 
58 
59 
60 
74 
57 
66 
66 
75 
76 
77 
63 
64 
71 
75 
80 
80 
82 
69 
70 
70 
64 
81 
57 
72 



Keyword 

CODE GENERATOR 

Keyword 

CODE GENERATOR 

Keyword 



Product number 
64818S004 

Product number 
64818S001 

Product number 



********none******** 64814 

64814 
64814 
64814 



uu.ff Description Report # 

03.02 printer arithmetic gives warning "integer not pointer size" 1650038430 

- -0 

uu.ff Description Report # 

03.30 bade code gen if local ptr to extrnl strcture is assgn vlu frm extrn ary 5000221788 

- -0 

uu.ff Description Report # 



02.01 Incorrect code generated in FOR loop. 

02.01 The library routine, DISPOSE, overwrites the ES register 



5000103432 
5000124313 



03.01 functional type change of a constant into multi-byte structure gen's err D200063750 

03.02 WITH construct causes wrong offset D200068759 



page 
83 

page 

84 

page 

86 
87 
95 
97 



Keyword index 



-0 



Keyword 



Product number uu.ff Description 



CODE GENERATOR 



********none******** 64814 

64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 
64814 



PASCAL 
PASS 1 
RUN-TIME LIBRARY 



Keyword 



03.02 
03.02 
03.02 
03.02 
00.01 
01.10 
02.00 
02.01 
02.01 
03.00 
03.00 
03.00 
03.00 
03.01 
03.01 
03.01 
03.01 
03.01 
03.03 
03.01 
03.02 
01.10 
01.10 



Wit h cons t ru 
Unsigned 8 t 
SRECURSIVE $ 
Pascal does 
Stack POP'S 
Illegal PUSH 
Wrong code g 
Using ES reg 
Incorrect ad 
Incorrect co 
bad code for 
Var. address 
pointers pas 
Mult iplicat i 
Code produce 
BX register 
Contents of 
FOR loop cou 
Using WITH s 
for loop w/ 
Functional t 
Problem with 
Real number 



ct causes wrong offset 

reated as signed value in FOR loop test. 

option defaults to incorrect mode (OFF) 
not report error for assignment of constant to structure 
exceed Stack PUSH'S when assignment made to ext var. 

instruction generated, 
enerated for expression in 'FOR' loop 
ister without init alizat ion - REP M0VSB . 
dress calculated for beginning of ary in WITH stamnt 
de gener. when shift function operand is mult, dimen 

accessing parameters in nested procedures 
es incorrect inside nested WITH statements 
sed as procedure parameters not fully dereferenced, 
on result stored in CX and overwritten when counter 
s an #1102 error - reg. needed but not available 
gets overwritten when accessing arrays of records 
register A gets overwritten when accessing mult, arrys 
nter gets destroyed when loop includes multiple WITH's 
tatement and complex record structure causes bad code 
counter = unsignd 8 type uses BX twice 
ype changes not always evaluated correctly 

Pascal I/O library (PIOLIB). 
comparisons may not 'evaluate' correctly. 

- -9 



array 



reg 



Report # page 

D200068767 99 

D200075952 101 

D200077875 102 

D200079194 104 

1650018689 85 

D200023283 93 

5000118844 86 

1650004705 85 

5000134817 88 

5000138388 88 

5000207845 91 

D200053710 94 

D200078642 102 

need 5000163824 89 

5000171876 90 

5000171884 90 

of rd 5000171900 91 

D200065060 95 

5000221994 92 

5000197624 91 

D200079251 105 

D200019273 93 

D200022137 93 



Product number uu.ff Description 



********none******** 64847 
CODE GENERATOR 64847 

64847 
PROBLEM ON VAX 64847 



00.46 In macros, "" and ' ' are not equivalent. 

00.00 Problem with negative displacementwit h SBO SBZ instructions. 

00.46 Autoinc rement with indirect addressing does not assemble correctly. 

00.00 *PRODUCT # CHANGE on the VAX* From= 64xxxS003 To=64xxxM003 



Report # page 



D200035220 
5000232959 
5000121830 
D200093369 



106 
106 
106 
107 



Keyword 



Product number uu.ff Description 



********none******** 64286 
ENHANCEMENT 64286 

64286 
64286 



01.04 Answer to "Emulate SCR?" is automatically changed to "yes" 
01.03 Cannot single step through a Software Breakpoint 

01.03 MASK, STATUS, and IC are not always cleared when running from reset. 

01.04 Enhance the register display to show the Pending Interrupt Register 



-0 



Keyword 



Product number uu.ff Description 



********none******** 64882 

64882 
TRANSFER 64882 



01.20 VAX help on MAPBUS command causes system error 

01.70 64100 cluster disk free list is corrupted so there is not enough space 

02.00 CSIB process does not come up on system bootup 



Report # page 



5000224022 
5000164004 
D200066357 
D200068957 



108 
108 
109 
109 



Report # page 

1650019257 110 
D200069104 110 
D200082669 110 



Keyword index 

Keyword Product number 

******** none******** 648 83 



-0 



Keyword 



uu.ff Description 

01.00 Transfer does not handle imbedded linefeeds in binary files 

- -0 
Product number uu.ff Description 



********none******** 64880 

64880 
TRANSFER 64880 



Keyword 
PROBLEM ON VAX 

Keyword 



Product number 
64857 

Product number 



********none******** 64100 

64100 
64100 
64100 
64100 
64100 
COPY 64100 

DC600 64100 

64100 



Keyword Product number 

********none******** 64285 

Keyword Product number 

********none******** 64851S001 

Keyword Product number 

********none******** 64851S003 



Keyword 



Product number 



e names 



********none******** 64274 

64274 



01.10 Invalid file names are not detected by the transfer utility 
01.60 Debug file transfers may not function with 14 character fil 
01.06 Bad file format does not cause error in transfer. 

- -S 

uu.ff Desc ript ion 

00.00 *PR0DUCT tt CHANGE on the VAX* From= 64xxxS003 To=64xxxM003 

- -P 

uu.ff Desc ript ion 

02.01 Formatting a floppy from a command file sometimes is unsuccessful. 
02.04 Comment is taken as a parameter when a null parameter is passed. 

02.06 Logical operators generate M0 error. 

02.07 Unique label is flagged as undefined in macro expansion. 
02.07 Instructions assembling differently than previous assembler. 
02.07 Phase error incorrectly reported on 64000 and hosted assemblers. 
02.01 "copy f:link_com to display" doesn't display all attributes of "f". 
00.01 64000 backup from 7946 to 9144 with 150' tape produces wrong message 
02.04 No multi-tape backup strategy for discs > 64MB on the 64000. 

- -M 
uu.ff Description 

01.00 Inverse assembly for 1E91H is incorrectly shown as SUB *- , E, 

- -S 
uu.ff Desc ript ion 

01.60 expressions of the form 123456.78 cause errors 

- -S 
uu.ff Description 

01.60 expressions of form 123456.78 cause errors 

- -S 

uu.ff Desc ript ion 

01.04 Bad display of trace data with 8-bit UDE 

01.04 modify memory starting at odd addresses does not always work 



Report # page 
D200082636 111 

Report # page 

D200019265 113 
1650018721 112 
5000219204 112 

Report # page 
D200093393 114 

Report # page 



5000111666 
D200062604 
5000202770 
1650033209 
5000189985 
D200085050 
D200027953 
1650006908 
5000181552 



115 
117 
116 
115 
116 
118 
117 
115 
116 



Report # page 

5000223792 119 

Report # page 

D200081620 120 

Report # page 

D200081638 121 

Report * page 



D200043828 
D200046623 



123 
123 



Keyword index 



Keyword Product number 

**#**#**none******** 64274 



uu.ff Description 

01.05 run until <addr> fails from reset when reset points to user code. 



Report # page 
5000241562 122 



Keywo rd 



Product number uu.ff Description 



Report # page 



********none******** 64808S004 

64808S004 
64808S004 
64808S004 
64808S004 

MENUS 64808S004 



01.20 Pmon flags a syntax error when attempting to append files 
01.20 User softkey display should be erased after shell escape 



1650036525 124 

D200077495 124 

01.20 pwd truncates the /net/system portion of the path when RFA'ed to system. D200080135 125 

01.20 Pmon command completion intermit tantly fails after completion error. D200080721 125 

01.20 Command search algorithm should match the softkey package. D200081141 125 

02.00 Pmon command completion via shell variables not working correctly 1650038521 124 



-8 



Keyword 



Product number uu.ff Description 



********none******** 64824 

64824 
64824 
64824 
64824 
64824 
64824 
64824 
64824 
64824 
64824 
CODE GENERATOR 64824 
PASS 1 64824 



Keyword Product number 

********none******** 64824S004 



01.01 Incorrect transfer address when linking 9 or more files. 
01.03 Error using switch (*x++). 

01.03 RETI is not generated when exiting an interrupt procedure. 
01.03 Array is being placed in the PROG section rather than data. 

01.03 INT Multiplication of short by negative constant with SHORT_ARITH. 

01.04 += operator does not work for pointers to structures. 

01.04 ZDconvert library module has two errors in the ZDdwo rdt oword routine. 

01.04 . 

01.04 +=, -=, *=, & /= may fail to auto vars with SRECURSIVE 0N$ 

01.04 Warning message text is incorrect. 

01.04 MOD operation returning the wrong value. 

01.04 Floating point division of 2 constants generates incorrect result 

01.03 DIV, MOD and COMParisons may do unsigned estend of signed values 

- -8 
uu.ff Desc ript ion 

01.20 Double word divide library returning incorrect result. 

- -8 



Keyword 



Product number uu.ff Description 



********none******** 64823 

64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 
64823 



01.03 
01.03 
01.03 
01.03 
01.03 
01.03 
01.03 
01.03 
01.03 
01.04 
01.04 
01.04 
01.04 



Report # page 



D2000 
50001 
50001 
50001 
D2000 
50002 
50002 
D2000 
D2000 
D2000 
D2000 
D2000 
D2000 



Unbelieveable amount of library code linked for no-line program. 

Libraries reference procedures not actually needed. 

FOR statement with SIGNED_BYTE produces incorrect code. 

functional type change of a constant into multi-byte structure gen's err 

Code generated by compiler increased 12% with latest version. 

Links not correctly established during calls of nested procedures. 

Certain variable accesses by nested procedures may not work 

Function Calls via pointer may fail 

Pascal does not report error for assignment of constant to structure 

Code generated by compiler increased 12% with latest version. 

Bad code generated when CASE expression involves addition of two bytes. 

Signed_32 divide returns wrong result. 

Unsigned_8 treated as signed value in FOR loop test. 



38778 
70654 
72825 
73278 
71373 
31605 
33866 
75044 
79079 
80374 
81471 
77222 
71431 



130 
127 
127 
128 
130 
128 
129 
131 
132 
133 
133 
132 
131 



Report * page 
5000226605 135 

Report # page 



50001 
50001 
50001 
D2000 
D2000 
D2000 
D2000 
D2000 
D2000 
50001 
50001 
50002 
D2000 



61000 
61034 
82014 
63875 
66761 
71332 
71340 
71423 
73031 
63287 
90629 
17927 
76067 



136 
137 
138 
140 
140 
141 
142 
143 
144 
137 
139 
139 
145 



Keyword index 



Keyword 



Product number uu.ff Description 



********none******** 64823 
ADDR 64823 

PASS 1 64823 

PASS 2 64823 



Keyword Product number 

********none******** 64823S003 



01.04 Compiler may confuse similar parameters in different subroutines 

01.03 ADDR ( x ) generates incorrect code is x is of type BYTE. 

01.03 Functional type changes not always evaluated correctly 

01.01 Incorrect code generated when set elements are passed as parameters. 

- -8 
uu.ff Desc ript ion 

01.70 Nested external procedure call causes bad code to be generated. 

- -8 



Keyword 



Product number uu.ff Description 



********none******** 64820 

64820 
CODE GENERATOR 64820 
PASS 1 64820 



01 
01 
01 
01 



06 Array is being placed in the PROG section rather than data. 
06 Warning message text is incorrect. 

.06 Floating point division of 2 constants generates incorrect result 
03 DIV, MOD and COMParisons may do unsigned estend of signed values 



■8 



Keyword 



Product number uu.ff Description 



Report t page 



D200079301 
5000186742 
D200071365 
1650011585 



146 
138 
142 
136 



Report # page 
5000224204 148 

Report # page 



D200076760 
D200080341 
D200077107 
D200079137 



149 
150 
149 
149 



Report # page 



********none******** 64816 

64816 
64816 

PASS 1 64816 



01.11 functional type change of a constant into multi-byte structure gen's err 

01.12 Unsigned_8 treated as signed value in FOR loop test. 

01.12 Pascal does not report error for assignment of constant to structure 

01.12 Functional type changes not always evaluated correctly 



D200063834 
D200076026 
D200079210 
D200079277 



152 
152 
153 
154 



- -8 



Keyword 



Product number uu.ff Description 



********none******** 64233 

64233 
64233 



01.07 Monitor displays wrong value for R15 and SSTK 

02.00 User interrupts are not serviced for 17ms after analysis generated 

02.00 Can't find symbols loaded with more address bits than specified. 



Report # page 

5000137869 156 

break 5000151431 156 

D200071415 157 



SRB detail reports as of 09/01/88 Page: 1 

Number: 1650038281 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

pwd truncates the /net/system portion of the path when RFA'ed to system. 

Problem: 

When using the HP 64000-UX products and netunaming across the LAN 
to another system, such as a compile server, the HP-UX command 
"pwd" which is used by the HP64000-UX product to tell what the 
local directory is, truncates the "/net/system" part of the path. 

This is a HP-UX operating system defect. It is not a defect in 

the HP 64000-UX application software. As soon as this defect is 

fixed in HP-UX, it will work correctly when using the HP 64000-UX 
applications. 

Signed off 01/14/88 in release Z01.80 

Number: 5000169474 Product: 64000-UX OP-ENV 300 64801S004 01.00 

One-line description: 

No error message given when opt run on memory board. 

Problem: 

64000 UX Options Test. 

No error or warning is given if a user tries to do options test on a 

memory board in the 64120 cardcage. The test for memory must be done 

through the memory controler board. The 64000 (classic) gives an error 

ERROR: No test availabe for selected card. 

The 64000-UX gives file not found error and the file 

/usr/hp64000/inst/pv/pv01f8 (for the 128k memory board). It looks 
for the board id number and puts "pv" in front of it for the file name 
it looks for. The user has no clue as to what is wrong. He only knows 
that file pv01f8 does not exist. 

Temporary solution: 

There are no performance verification tests available for memory 
boards. All memory boards are tested when the memory controller is 
tested. Do not select memory boards for testing within opt. 

Signed off 01/14/88 in release Z01.80 

Number: 5000185066 Product: 64000-UX OP-ENV 300 64801S004 01.00 

One-line description: 

Edbuild does not work whether invoked by the user or the emulator. 

Problem: 

About the EDBUILD Command fails. 

The customer system can not get response for the edbuild command, then 
a "load" command.. (i» 8086 emulator mode) do not, either. 

-- THE CUSTOMER SYSTEM CONFIGURATION -- 
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CPU - HP9000/320 

( The swap area = 10 Mbytes 
HP-UX rev. 5. 172 ) 



An absolute file name is sys.X ( sys.L, sys.K ). 
The program (sys.X) is large of 5_Mbytes on source. 
COMMANDS: 

edbuild sys, edbuild -h2 sys, edbuild -f Alist sys, edbuild -C sys 
edbuild -f Alist -h2 sys # All commands not response forever. 

Temporary solution: 

No workaround at this time. 

Signed off 01/14/88 in release Z01.80 



Number: D200076588 Product: 64000-UX OP-ENV 300 64801S004 

One-line description: 

If second card cage used in pv, it may not be released 

Problem: 

If second card cage used in pv, it may not be released. 

Problem: 

If a second card cage is needed to test a card (e.g., use 
a card in a second cage to test 1MB), if the second 
card is the last one allocated it may not be freed 
when option_test (opt) is exited. 

Workaround: 

After opt is finished, execute msunlock and msinit. 



Temporary solution: 

After opt is finished, execute msunlock and msinit. 



01.50 



Signed off 01/14/88 in release Z01.80 



Number: D200076620 Product: 64000-UX OP-ENV 300 64801S004 01.50 

One-line description: 

Pressing return during a cycle command causes pv to hang 

Problem: 

When starting Performance verification, if the cycle softkey is 
pressed followed by the Return key, PV then says "Awaiting command" 
and the "stop" softkey is available, but the test is hung. 

Temporary solution: 

Do not press the return key after the "cycle" softkey. 



-4 
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Number: D200076679 Product: 64000-UX OP-ENV 300 64801S004 01.50 

One-line description: 

Ms in it crashes opt test user. 

Problem: 

msinit crashes another user's opt test. One user is in the opt test 
display, and does something ( anything that talks to the cage ). The 
other guy runs "msinit", and gets the message 'inconsistent module data, 
cleaning up'. When the opt test user then tries to do something, opt 
test is hosed. 

Temporary solution: 

Do not run msinit while any other user is running opt. 

Signed off 01/14/88 in release Z01.80 

Number: D200077008 Product: 64000-UX OP-ENV 300 64801S004 01.50 

One-line description: 

If /usr/hp64000/lock does not exist, msconfig gives odd messages. 

Problem: 
Text: 

if /usr/hp64000/lock does not exist, msconfig gives odd messages 

If, for some reason, the /usr/hp64000/lock directory is removed 
(which never happens unless the customer does so!), and if 
there were some measurement_systems defined prior to the lock 
directory being removed, the command 

remove_system <anysys> 
gives a status message of 

"system <anysys> in use by ???" 

Temporary solution: 

As superuser, recreate the directory /usr/hp64000/lock with the 
command "mkdir /usr/hp64000/lock" . Then run msconfig again and 
remove the measurement system. 

Signed off 01/14/88 in release Z01.80 



Number: D200077941 Product: 64000-UX OP-ENV 300 64801S004 

One-line description: 

Msinit may autoconf igure incorrectly. 

Problem: 

Assume the following cards in the card cage: 

internal analyzer (wide or narrow) 

emulator #1 

state system (with EBPP) 



01.00 
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When configuring with msinit, the user will be asked for an analyzer 
for emulator #1. If the internal analyzer is selected, msinit 
automatically configures the EBPP as the analyzer for emulator #2 
without asking any more questions This can be annoying if the state 
system is in fact connected to emulator #1. 

Temporary solution: 

Put the emulator without the analyzer (#2) in lower numbered 
slots. When msinit asks for the analyzer to be used, hit return 
to specify no analyzer. 

Signed off 01/14/88 in release Z01.80 

Number: D200077958 Product: 64000-UX OP-ENV 300 64801S004 01.00 

One-line description: 

HP enhancements are too slow to run softkeys. 

Problem: 

Softkeys track too slow on HP Terminals. Softkey lines are written 
out each time they change. Each time they are written, 400 characters 
are sent to the display; 80 for the contents of the line and another 
320 for the underlining enhancement. The extra characters result is 
very slow tracking because of all the I/O. 

Temporary solution: 

All underlining can be turned off by creating a customized 

terminfo entry that does not have underlining capability. 

As Superuser, 

1) untie TERM >file #TERM is the value of the TERM variable for 

#that terminal 

2)Edit the file and a) replace the top line with an entry that uniquely 

identifies the new terminal type. The top line contains valid names 

that represent the characteristics defined in this file. 



Ex. 



2392. Jdb, 



b) Remove the entry called "smul". 

3)Save the file. 

4)tic file. 

5)Set the TERM variable to the new terminal type. 
TERM=2392.Jdb 
export TERM 

Signed off 01/14/88 in release Z01.80 
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Number: D200079038 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

option_test multitest can't handle more than 24 cards 

Problem: 

When one attempts to do multitest, including all_cages, all_slots, 
the option_test software quits after configuring 24 cards (6 68020 
emulators). If each emulator is included separately, option_test 
will configure all 8 emulators, but it goes into the weeds during 
cycling of the test and reports multiple failures even though no 
low-level display show any failures. In addition, the low-level 
displays may show only 3 test completed while the main-level 
display reports thousands. 

Temporary solution: 

Do not test more than 24 boards at a time with multitest. 

Signed off 01/14/88 in release Z01.80 

Number: D200079095 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

EDBUILD IS NOT WORKING PROPERLY 

Problem: 

Edbuild runs much slower when a code segment is at a higher address than 

a Data segment. 

This problem is not really related to the segment type, but rather to 
the type of symbols in the segments. 

If the segments comprising a program are ordered such that one or ones 
containing no global symbols are loaded at the highest addresses 
in the program and there are no global symbols at higher addresses, 
edbuild will "forget" about the segment and all the symbol information 
within that segment. This leads to edbuild running faster because it 
is not processing all the symbol information. 

Note that when it runs faster in this case, edbuild is working 
incorrectly . 

Temporary solution: 

To make edbuild work correctly, add one or more global symbols to 

the segment at the highest address. 

Signed off 01/14/88 in release Z01.80 



Number: D200079293 Product: 64000-UX OP-ENV 300 64801S004 



01.70 



One-line description: 

Multiple <cr> after selecting card will leave softkeyw in an odd state. 

Problem: 
If you 

1) select a card 

2) press carriage-return several times before the next screen 

- -4 
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displayed 

then 

the softkeys show the softkeys for the 'selection' mode, 
but the display shows the display for the test selected. 

WORKAROUND: 

don't hit return until the next display appears. 

Temporary solution: 

don't hit return until the next display appears. 

Signed off 01/14/88 in release 201.80 

Number: D200079509 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 
Incompatible /etc/update programs. 

Problem: 

The version of /etc/update which is shipped with HP 64000-UX 

products is NOT compatible with the HP-UX version. This results 

in some rather unique problems when updates for the two types of 

products are to be loaded (i.e., "Cannot find table of contents"). 

Temporary solution: 

Unload the update tools each time a new update is performed. 
This will insure that a compatible /etc/update is used for 
the appropriate software. 

Signed off 01/14/88 in release Z01.80 

Number: D200080093 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

64000-UX processes do not die when modem carrier is lost. 

Problem: 

When in measurement system via a modem line connection, if the carrier 
is lost then the processes do not get killed. Yet the highest level 
process (your shell) goes away. This results in another getty being 
spawned on this line even though meas. sys. is still reading and writing 
to this port. 

Temporary solution: 

None exists at this time. 

Signed off 01/14/88 in release Z01.80 

Number: D200081984 Product: 64000-UX OP-ENV 300 64801S004 01.60 

One-line description: 

Processes sometimes left running after parent has stopped. 

Problem: 

Sometimes, when the parent process to a measurement system is killed 

some of the measurement systems processes are left running. Please 
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change the behaviour of the products so that these processes die 
nicely. 



Temporary solution: 

If the tty associated with the process is a pty, then you can 

release the processes by 

cat < ptyxx 
This causes the pending output to be flushed, and the processes will die 
naturally. 



Signed off 01/14/88 in release Z01.80 



01.60 



Number: D200078923 Product: 64000-UX OP-ENV 300 64801S004 

One-line description: 

Search command files via "PATH" variable 

Problem: 

Allow search for command files using the PATH variable. 

Temporary solution: 

Command files must be specified with an absolute path or reside in 

the current working directory. 

Signed off 01/14/88 in release Z01.80 

Number: D200080101 Product: 64000-UX OP-ENV 300 64801S004 01.60 

Keywords: ENHANCEMENT 

One-line description: 

64000-UX uses TERMINFO database only partially. 

Problem: 

64-ux software uses TERMINFO database only partially. There 

is no description of the fact that it uses the TERMINFO database or the 

fact that it uses it in a way inconsistent with the definitions in 

section 4 of the HPUX reference manual. 

Signed off 01/14/88 in release Z01.80 
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00.01 



One-line description: 

Nested IF stmnt. with bit field structure members genrate incorr. code 

Problem: 

The following program generates incorrect code: 

"6809" 

$SEPARATE 0N$ 
SRECURSIVE 0FF$ 
unsigned short e; 
unsigned short a; 
struct {unsigned d:2; 

unsigned short c:2;} b; 

QUAO 

{ if (b.c « 1) 

{if ((a==6)l l(e==0)) 
{b.c=0;} } 
else 

{if ((a!-6)&&(e!-0)) 
b.c-0; 
} 
} 
main (){} 

If the members of the structure are not bit fields then this problem 
does not occur. 

The problem occurs after the else statemnet. The code generated for 
the line "{if ( (a! =6)&&(e! =0 ) ) " looks like: 

CLRB should be LDAB Dstatic+OOOOIH 

CMPB #00 6H 

BNE QUA01_11 

JMP QUA1_6 
QUA01_11 

should be LDAB Dstatic 

CMPB #000H 

BNE QUA01_12 

etc. 

Since the variables are not loaded into B the comparisons are meaningles 
s. 

Temporary solution: 

The following code might be used instead: 

{ if ((B.C==1)&&((A==6)| I (E--0))) 

{B.C=0;} 
else 
{if ( (B.C!=1)&M (A!-6)&&(E!-0))) 
{B.C=0; } 
}} 

- -8 
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Number: D200015073 Product: 6800 C 
Keywords: CODE GENERATOR 



64821 



01.04 



One-line description: 

Using a pointer dereference as an array index generates incorrect code. 

Problem: 

Given the following program, an incorrect "LDX ,X" is generated. 

"C" 

"6800" 

struct { 

struct { 

short a; 
short b [5] ; 
} c; 
short d; 
} *p; 
short t; 
main ( ) { 

t = p- >c.b[ p->d ] ; 
} 

After loading accumulator B with p->d by the "LDAB ,X" instruction, 
two subsequent loads of X are generated. 
LDX Dmain 
LDX ,X 
The "LDX ,X" is the incorrect instruction. 

Temporary solution: 
Define the structure as follows, 
struct { 

struct { 

short a; 
short b[5] ; 
} c; 
short d; 
} str; 
struct str *p; 
Then change the source line as follows for less and correct code, 
t = p -> c.b[ str.d ] ; 

Signed off 01/14/88 in release Z02.10 



Number: D200015347 Product: 6800 C 
Keywords: CODE GENERATOR 



64821 



01.04 



One-line description: 

Compiler doesn't reload register after value changes in a nested if expr 

Problem: 

In the following nested if expression, the compiler assumes the value of 

register D has not changed when it makes the comparison of test to 

0X01. 

- -8 
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„ c „ 

"6800" 

int test=0x0040; 

main () { 

if ( test & OxffOO) { 

if ( test & 0x01 ) ; 

} 
} 

Register D is initially loaded with the value of test, anded with OxffOO 
and then set equal to the result of the and. The code for the next if 
begins by anding the D register with 0x01 before reloading D with the 
value of test. 

Temporary solution: 

Turn $AMNESIA 0N$ before second if statement. 

Signed off 01/14/88 in release Z02.10 



Number: D200067629 Product: 6800 C 



64821 
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One-line description: 

Assigning to bitfield causes entire structure to be reset. 

Problem: 

If you have a static structure containing bit fields and you 

set one of the members to the entire structure is reset. 



"C" 






"6800" 




unsigned int 


i ; 


struct { 




unsigned 


one 




unsigned 


two 




unsigned 


three 




unsigned 


four 




unsigned 


five 




unsigned 


six 




unsigned 


seven 




unsigned 


eight 




} bit_struct; 




main( ) { 







bit_struct. f ive = 0x01; 
bit_struct. eight = 0x00; 



} 



/* entire structure is reset. */ 



Temporary solution: 

The only known work around at this time is to declare a local 
(automatic) structure of the same type as the external. Upon 
entering a function equate the two structures and do this 
again just before the function is exited. This will cause 
excessive code generation. 

Signed off 01/14/88 in release Z02.10 

- -8 
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Number: D200076802 Product: 6800 C 



64821 



11.07 



One-line description: 

Array is being placed in the PROG section rather than data. 

Problem: 

Compiler puts array that should be in DATA section in PROG section 

Example: 

"C" 

"Z80" 

char array[12] ; 

The above code when compiled creates an array of twelve bytes that will 
reside in the PROG section. This should be placed in the DATA section. 

Temporary solution: 

Generate an ASM_FILE and edit the ASMProcessor file to place 

the array under the DATA counter. 

Signed off 01/14/88 in release Z02.10 



Number: D200077149 Product: 6800 C 
Keywords: CODE GENERATOR 



64821 
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One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088" 

main( ) 

{ 

double xx ; 

xx = 2.0/3.0; 

xx = 2.0; 
} 
xx is assigned the value 2.0 by both statements. 

This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 

xx = 2.0/y; where y = 3.0; 

Signed off 01/14/88 in release Z02.10 



Number: D200079145 Product: 6800 C 
Keywords: PASS 1 
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One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 
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short 


s; 




unsigned short us; 


main( 




{ 




if 


( (s/usPOxffff 




error! ) ; 

( ( us'/is) 0x007f 


if 




error ( ) 




if 


(us==s) 
error! ) 




if 


(s! =us) 
error ( ) 




if 


(s<us) 
error ( ) 




if 


(s>us) 
errorf ) 





Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SHORT ARITH 0FF$ 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z02.10 

Number: D200080358 Product: 6800 C 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 

"C" 

"68000" 

unsigned int a; 

main!) 

{ 

a=0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 



64821 
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$WARN 0FF$. This will turn off all warning messages. 
Signed off 01/14/88 in release Z02.10 
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One-line description: 

Generates bad code for parameter as ADDR of component. 

Problem: 
"6800" 

{ PascBug25: Pascal generates bad code for parameter as ADDR of 
component. 

Pascal is generating bad code if a parameter passed to a pro- 
cedure is the address of the first element of a record, and that 
record is specified in a WITH statement. 

The compiler is erroniously generating an indirect flag preceding 
the parameter specifier in the calling sequence. 

To observe the bad code, try: 

"compile PascBug25 listfile printer options expand" } 

PROGRAM PascBug25; 

TYPE PTR = "INTEGER; 

VAR V: RECORD 

element_l: INTEGER; 
element_2: INTEGER; 
END; 



PROCEDURE proc (pointer: PTR); EXTERNAL; 

BEGIN 

WITH V DO 
BEGIN 

proc (ADDR (element_l) ) ; {bad code - addr passed with indirection) 
proc (ADDR (element_2) ) {good code) 
END 
END. 

Temporary solution: 

Avoid use of "WITH" statement. 

Signed off 01/14/88 in release Z01.90 



Number: D200063123 Product: 6800 PASCAL 



64811 



01. 10 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 



SRB detail reports as of 09/01/88 


Page: 


15 


SRB detail reports as of 09/01/88 Page: 


16 


"processor ' 






END. 




PROGRAM BAD_DATA; 
















Temporary solution: 




TYPE EVENT = RECORD 






USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 




A 


BYTE; 










B 


BYTE; 










C 


INTEGER; 






"PROCESSOR" 




D 


BYTE; 










END; 






SEXTENSIONS 0N$ 




VAR EVENT 1 : EVENT; 






PROGRAM DOLOOP; 

VAR SECTORNUM, STOPSECTOR : UNSIGNED 16; 




PROCEDURE GENERATOR ( ) ; 






A : INTEGER; 




BEGIN 










EVENT1 := EVENT(O); { THIS ASSIGNMENT 


RESULTS IN BAD DATA 


} 






END; 






BEGIN 




BEGIN 






STOPSECTOR := UNSIGNED_16(247), 




END. 






FOR SECTORNUM := UNSIGNED_16(0 ) TO STOPSECTOR DO BEGIN 




Temporary solution: 










No temporary solution. 






A : = 5; 
END; 




Signed off 01/14/88 in release Z01.90 






END. 




Number: D200075861 Product: 6800 PASCAL 


64811 


01.20 





One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

SEXTENSIONS 0N$ 

PROGRAM DOLOOP; 

VAR SECTORNUM, STOPSECTOR : UNSIGNED_8; 
A : INTEGER; 

BEGIN 

STOPSECTOR := UNSIGNED_8(247) ; 

FOR SECTORNUM := UNSIGNED_8(0) TO STOPSECTOR DO BEGIN 

A := 5; 

END; 



This works for values up to 8000H. 
Signed off 01/14/88 in release Z01.90 



Number: D200079178 Product: 6800 PASCAL 



64811 



01.20 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 

changes physical size), when it should generate a fatal error. It 

tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 
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"PASCAL" PREPROCESS 
"6809" 

{ Test program to demonstrate Pascal language defect } 
{ Functional type change of constant to multi-byte variable } 
PROGRAM PTEST101; 
^EXTENSIONS ON$ 
TYPE event = RECORD 

type : BYTE; 
qualifier: BYTE; 
msg : INTEGER; 
send_task: BYTE; 
END; 
VAR eventl: event; 
i: INTEGER; 
R: REAL; 

BEGIN 

{The following code is attempting to initialize} 

! the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 

eventl := event(O); {This code is incorrect Pascal} 

{Correct Pascal using individual assignments} 

eventl. type: =0 ; 

eventl . qualif ier:=0 ; 

eventl. msg: =0; 

event 1 . send_task : =0 ; 
END. 
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Signed off 01/14/88 in release Z01.90 
Number: D200079236 Product: 6800 PASCAL 
Keywords: PASS i 



64811 



01.20 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 



SEXTENSI0NS 0N$ 
PROGRAM PTEST; 



VAR 



S8 
U8 
S16 
U16 



SIGNED_8 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 
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BEGIN 
U16 
U16 



UNSIGNED_16(S8) 
UNSIGNED 8(S8) ; 



(* signed extension of S8 
(* signed extension of S8 



- correct *) 

- incorrect *) 



S16 :» SIGNED_16(U8) 
S16 := SIGNED 8(U8) ; 



END. 



(* unsigned extension of U8 - correct *) 
(* unsigned extention of U8 - 1 incorrect 



Signed off 01/14/88 in release 201.90 
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Number: D200061556 Product: 68000 ASSEMB 64845 

One-line description: 

EQU is not working with DC correctly. 

Problem: 

The EQU pseudo when used with the DC psuedo causes incorrect 

object code to be generated. 

••68000" 



;VALUE IS 6 
; VALUE IS 5 



19 
01.10 



X 


EQU 


7 




DC.B 


X 


X 


SET 


X-l 




DC.B 


X 



Temporary solution: 

No temporary solution known at this time. 

Signed off 01/14/88 in release Z02.10 



Number: D200093344 Product: 68000 ASSEMB 
Keywords: PROBLEM ON VAX 
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00.00 



One-line description: 

♦PRODUCT # CHANGE on the VAX* From= 64xxxS003 To=64xxxM003 

Problem: 

This Service Request has been entered to inform users of the product 

THAT: 

The *PR0DUCT NUMBER has CHANGED on the VAX version of this product 

FROM (OLD Product Number) = 64xxxS003 < The real change being 

< the "S" changed to "M" 
TO (NEW Product Number) = 64xxxM003 < in this Product Series 

(The "xxx" in the above to be filled in with the Product Number 
against which this SR is entered... This text applies to many 
SR's and is generic in nature.) 

The above event happend without a change to the REVISION CODES on the 
PRODUCT. 

This event happend on the revision code that was used to sign off 
this Service Request. 

Signed off 08/31/88 in release A02.10 



SRB detail reports as of 09/01/88 

Number: 1650026583 Product: 68000 C 

One-line description: 
Invalid error 60 flagged. 



64819 



Page: 20 

01.10 



Problem: 

When multiple assignments which include a function call are made 

on a single line error 60 is incorrectly flagged. 

"C" 
"processor" 

extern int *func( ) ; 

main() { 

int *xptr; 
char *cptr; 

cptr = (char *)xptr = fund); 

) 

Temporary solution: 

Break the assignment across two lines. 

"C" 
"processor" 

extern int *func( ) ; 

mainO 

{ 

char *cptr; 
int *xptr; 

xptr = func( ) ; 

cptr = (char *)xptr; 



Signed off 01/14/88 in release 202.10 



Number: 5000171124 Product: 68000 C 



64819 



01.09 



One-line description: 

Result is invalid if terenary expression evaluates to false. 

Problem: 

Incorrect code is generated when the result from a conditional 

statement is false. 

"C" 

"68000" 

struct s_type { 

int fieldl; 
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int field2; } ; 

extern int my_funct(); 

int test(sp) 
struct s_type *sp; 

{ int loc_var = 0; 

sp -> field2 = ( loc var ? my functO : 

} 

ma int) {} 



The expanded code for the above program demonstrates the problem. 
The offset into the the structure is calculated only for the 
true condition. If a false condition is the result the program 
jumps before it calculates the offset. 

Temporary solution: 

Replace the terenary expression with an equivalent if-then-else. 

Signed off 01/14/88 in release Z02.10 



Number: 5000188839 Product: 68000 C 64819 

One-line description: 

$LIST 0N/0FF$ doesn't work correctly. 

Problem: 

$LIST 0N$ and $LIST 0FF$ directives not working properly. 

For Example: 

"C" 

"68000" 

$LIST 0FF$ 

/* comment 1 off */ 

$LIST 0N$ 

/* comment 1 on */ 

main! ) 

{} 

When compiled with the output option creates: 

"C" 

"68000" 

SLIST OFF$ 

/* comment 1 off */ 

SLIST 0N$ 

/* comment 1 on */ 

Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release 202.10 



01. 10 



SRB detail reports as of 09/01/88 
Number: 5000204586 Product: 68000 C 
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One-line description: 

Wrong floating point value assigned in a terenary expression. 



Problem: 

64000 - UX C Compiler rev. 1.1 

Incorrect value generated when: 

"C" 

"68000" 

$FAR$ 

$CAL_ABS_LONG$ 

$LIB_ABS_L0NG$ 

float testl, testlO; 

float resultl, result2, result3, result4; 

ma int) { 

float number = 10; 

float num = 1; 

testl = 1; 

testlO = 10; 

resultl = (testl>2) ?number:num; 

result2 = (testl>2) ?(number+0 ): (num+0) ; 

result3 = ( testl<2) ?number;num; 

result4 = (testl<2)?(number+0) : (num+0) ; 

Signed off 01/14/88 in release Z02.10 



resultl should = result2 but doe 
sn't. when the var name is alone 
without ( +#) the results are 
odd. The same thing happens for 
choosing the "TRUE" value. 



-resultl 


= 


3c000000h = 1/128 


-result2 


= 


3f800000h = 1.0 OK! 


-result3 


= 


49000000h = 2**19 


}-result4 


= 


41200000h = 10 OK! 



Number: 5000206649 Product: 68000 C 



64819 



01.09 



One-line description: 

Two external declarations are made for one function. 

Problem: 

Compiler makes double external symbols. 

Example 

fl() 

{ extern f ( ) ; 



f2() 

{ extern f( 



> 

Compile this file, make 

EXTERNAL F 

EXTERNAL F 

Temporary solution: 

The file will still link with no errors so you can ignore the 
problem. Or pull the declaration of "extern f()" outside 
of the procedures which reference f() ( in other words make 
the declaration at the top of your source file.) 

Signed off 01/14/88 in release Z02.10 



SRB detail reports as of 09/01/88 
Number: 5000223099 Product: 68000 C 
Keywords: ENHANCEMENT 



64819 



Page: 23 

01.90 



One-line description: 

Generate XREF from compiler which is readable by EDT. 

Problem: 

Antoinette Burkett sc: 

Generate a listing with cross references from a C compiler program 
on the VAX. When editing that file using edt an error message will 
be encountered : error reading from input file filename : file 
specification '/irms-w-rtb 512 byte record too large for users 
buffer, press return to continue. The edt editor will then show 
all parts of the file except the xref. 

Signed off 01/14/88 in release Z02.10 



Number: 5000234237 Product: 68000 C 



64819 



01.02 



One-line description: 

68008 libraries cause target processor disagree errors. 

Problem: 

Linker gives error message : target processors disagree file 

/usr/hp64000/lib/clib/168008/real_lib.R ! 

Signed off 01/14/88 in release 202.10 



Number: D200014340 Product: 68000 C 
Keywords: CODE GENERATOR 



64819 



01.07 



One-line description: 

Bad code using $RANGE$ or $DEBUG$ with $CALL_PC_LONG$ or $LIB_PC_LONG$ 

Problem: 

Bad code is generated when calling functions and the compiler 
directives $RANGE 0N$ or $DEBUG 0N$ are used in combination with 
the directives $CALL_PC_LONG$ or $LIB_PC_LONG$. For example, 

SDEBUG ON, LIB_PC_LONG$ int i; 

int f ( ) { return 0; } 

mainU { i - f() * 2; /* Produces bad code */ 
BSR F * CALL F 

MULS #2,D7 -MULTIPLY RESULT IN D7 TIMES 2 
MOVE.L D7,-[A7] ;PUSH PARAMETER FOR Zoverf low_sl6 
MOVE.L #Zoverflow_sl6[PC],D7 ;ERR0RM D7 DESTROYED!! 
JSR -6[PC,D7.L] ;CALL Zoverf low_sl6 VIA PC LONG METHOD 
M0VE.W D7.I ;WR0NG VALUE STORED, D7 CONTAINS BAD DATA!! 

Temporary solution: 

Avoid the combination of functions, $RANGE$ or $DEBUG$, and 
$CALL_PC_LONG$ or $LIB_PC_ ! _LONG$. The example above may be rewritten 
to achieve the same functionality. 



SRB detail reports as of 09/01/88 
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i = f(); /*STATEMENT DOES NOT CAUSE CALL TO OVERFLOW ROUTINE*/ 

i = i * 2; /"OVERFLOW ROUTINE CALLED HERE BUT DATA IS NOT IN D7*/ 

Signed off 01/14/88 in release Z02.10 



Number: D200069666 Product: 68000 C 



64819 



01.09 



One-line description: 

Compiler aborts when it encounters a legal structure declaration. 

Problem: 

The compiler aborts for a legal structure declaration. 

"C" 
"processor" 

structure tag { int varl; } A; 

ma int ) { 

A. varl = 1; 

> 

The compiler allocates 110H bytes of storage and then aborts. 



Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z02.10 



Number: D200077065 Product: 68000 C 
Keywords: CODE GENERATOR 



64819 



01. 10 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088" 

main( ) 

{ 

double xx ; 

xx = 2.0/3.0; 

xx = 2.0; 
} 
xx is assigned the value 2.0 by both statements. 

This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 
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xx • 2.0/y; where y = 3.0; 
Signed off 01/14/88 in release Z02.10 
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Number: D200079129 Product: 68000 C 
Keywords: PASS 1 



64819 



01.10 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 

Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SHORT_ARITH 0FF$ 

short s; 

unsigned short us; 



main! 



if ( (s/usPOxffff ) 

error! ) : 
f !(us%s)0x007f ) 

error ( ' 
f (us= = s). 

error! ) 
f (s!-us) 

error! ) 
f (s<us) 

error! ) 
if (s>us) 

error! ) 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release 202.10 



SRB detail reports as of 09/01/88 Page: 

Number: 1650009456 Product: 68000 PASCAL 64815 

One-line description: 

System reboot for syntax error. 

Problem: 

The following program will cause the 64000 station to reboot. 

"68000" 

PROGRAM TASK4; 
PROCEDURE TEST1; 



26 
00.01 



VAR 



REAL; 

BOOLEAN; 



BEGIN 

IF X>0.0 
IF X<0.0 
END; 



THEN 
THEN 



A := FALSE 
A :- FALSE 



{MISSING SEMI-COLON CAUSES PROBLEM} 
{THIS IF IS ALSO NEEDED. } 



Temporary solution: 

If the 64000 station reboots during a compilation check your code 

for this type of syntax error. 

Signed off 01/14/88 in release Z01.90 



Number: 1650019224 Product: 68000 PASCAL 



64815 



01. 10 



One-line description: 

Incorrect code generated for array which has boolean indices. 

Problem: 

Using boolean values as indices to an array will cause an incorrect 

offset to be generated. 

"68000" 

PROGRAM bool; 
$EXTENSIONS 0N$ 

VAR arr : ARRAY [ 1. . 4, BOOLEAN] OF BYTE; 
j : BOOLEAN; 



BEGIN 

j := FALSE; 
arr[l,j] := 1; 
arr[2,j] := 1; 



END. 



{ This is OK } 

{ offset is calculated incorrectly 
(200H + j). } 



Temporary solution: 

Use an indice of type integer rather than boolean. 



"68000' 



- -8 
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$EXTENSIONS 0N$ 

CONST TRUE - 1; 
FALSE = ; 

VAR arr : ARRAY[1. . 4,0. . 1] OF BYTE; 
j : INTEGER; 

BEGIN 

j := FALSE; 
arr[2,j] :=1; 

END. 

Signed off 01/14/88 in release Z01.90 



Page: 
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Number: 1650019331 Product: 68000 PASCAL 



64815 



01.10 



One-line description: 

Set manipulation results in incorrect code being generated. 

Problem: 

The compiler appears to miss a syntax error and instead generates 

bad code. 

"68000" 
$EXTENSIONS 0N$ 

PROGRAM set test; 



TYPE set_values 
set_type 

$EXTVAR 0N$ 

VAR operation 
x.y.z 
set_var 
values 

SEXTVAR 0FF$ 

set member 



0. .32; 

SET OF set_values; 



BYTE; 
INTEGER; 
set_type; 
set_values; 



INTEGER; 



BEGIN 



set_member 
set var 



:= 04; 

:= set_type[set_member] : 



{ I believe the customer wants to type cast set_member and therefore 
should use '()'. The compiler generates code to clear a 5 byte 
block beginning at the address of the variable operation. } 

END. 

Temporary solution: 

No temporary solution at this time. 



SRB detail reports as of 09/01/88 
Signed off 01/14/88 in release Z01.90 



Page: 
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Number: D200007179 Product: 68000 PASCAL 
Keywords: PASS 1 



64815 



00.00 



One-line description: 

C0MP_SYM file not purged when C0MP_SYM option not selected. 

Problem: 

If C0MP_SYM option is not selected when compiling, previously created 
C0MP_SYM file is not purged. Since this file can only cause trouble, it 
should be purged if the C0MP_SYM option is not specified. This only 
happens if you have 64330. 

Temporary solution: 

Purge the C0MP_SYM file before compiling. 

Signed off 01/14/88 in release Z01.90 



Number: D200063792 Product: 68000 PASCAL 



64815 



01.11 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 

"processor" 

PROGRAM BAD_DATA; 

TYPE EVENT = RECORD 



A 


BYTE; 


B 


BYTE; 


C 


INTEGER; 


D 


BYTE; 


END; 





VAR EVENT 1 : EVENT; 



PROCEDURE GENERATOR ( ) ; 
BEGIN 

EVENT1 := EVENT(O); { THIS ASSIGNMENT RESULTS IN BAD DATA 
END; 

BEGIN 
END. 



Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z01.90 
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Number: D200079202 Product: 68000 PASCAL 64815 01.12 


END. 




One-line description: 






Pascal does not report error for assignment of constant to structure 


Signed off 01/14/88 in release Z01.90 




Problem: 


Number: D200079269 Product: 68000 PASCAL 64815 


01.12 


The Pascal/64000 compiler fails to report an error when using 






the functional type change operator to attempt to assign an 


Keywords: PASS 1 




immediate constant to a multi-byte structure. 


One-line description: 




Since the Pascal/64000 compiler does not support structured constants, 


Functional type changes not always evaluated correctly 




there is no meaningful way to assign a constant to a structure. 






Each element must be assigned individually. 


Problem: 






Some functional type changes are not correctly evaluated. 


For example, 


The Pascal/64000 compiler does report an error 505 (Warning: type 


the following code illustrates the problem. 




changes physical size), when it should generate a fatal error. It 






tries to generate code for the illegal statement which will not 






produce the results expected by the user. 


SEXTENSIONS 0N$ 




The compiler should produce fatal Error #451: Structured constants not 


PROGRAM PTEST; 




implemented. 


VAR 




Here is a simple example and the workaround by explicit individual 


S8 


SIGNED 8 ; 




assignment statements. 


U8 


UNSIGNED 8 ; 






S16 


SIGNED 16 ; 






U16 


UNSIGNED 16 ; 




"PASCAL" PREPROCESS 






"6809" 


BEGIN 




{ Test program to demonstrate Pascal language defect } 


U16 := UNSIGNED 16(S8); (* signed extension of S8 - 


correct *) 


{ Functional type change of constant to multi-byte variable } 


U16 := UNSIGNED_8(S8) ; (* signed extension of S8 - 


incorrect *) 


PROGRAM PTEST101; 






SEXTENSIONS 0N$ 


S16 := SIGNED 16(U8); (* unsigned extension of U8 


- correct *) 


TYPE event = RECORD 


S16 := SIGNED 8(U8); (* unsigned extention of U8 


- incorrect *) 


type : BYTE; 


END. 




qualifier: BYTE; 






msg : INTEGER; 


Signed off 01/14/88 in release Z01.90 




send task: BYTE; 






END; 






VAR event 1: event; 






i: INTEGER; 






R: REAL; 






BEGIN 






{The following code is attempting to initialize} 






{ the multibyte record event to zeros. } 






{It should be interpreted as a Pass 1 error > 






{ Error #451: Structured constants not implemented} 






{ The code produced will be processor dependent } 






eventl := event(O); {This code is incorrect Pascal} 






{Correct Pascal using individual assignments} 






eventl. type: =0 ; 






eventl. qualifier: =0 ; 






eventl. msg: =0; 






eventl. send_task: =0; 






- -8 


- -8 
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Number: D200076844 Product: 6809 C 



Page: 



64822 
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01. Of 



One-line description: 

Array is being placed in the PROG section rather than data. 

Problem: 

Compiler puts array that should be in DATA section in PROG section 

Example: 

"C" 

"Z80" 

char array [12]; 

The above code when compiled creates an array of twelve bytes that will 
reside in the PROG section. This should be placed in the DATA section. 

Temporary solution: 

Generate an ASM_FILE and edit the ASMProcessor file to place 

the array under the DATA counter. 

Signed off 01/14/88 in release Z01.80 



Number: D200077180 Product: 6809 c 
Keywords: CODE GENERATOR 



64822 



01.08 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088 M 

main! ) 

{ 

double xx ; 

xx = 2.0/3.0; 

xx = 2.0; 
i 
; 

xx is assigned the value 2.0 by both statements. 

This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 

xx = 2.0/y; where y - 3.0; 

Signed off 01/14/88 in release Z01.80 



Number: D200079152 Product: 6809 C 
Keywords: PASS 1 



64822 



01.08 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 
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Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SH0RT ARITH 0FF$ 



short 


s; 




unsigned short us; 


main! 




{ 




if 


( (s/uspoxffff ) 




error! ) : 
KusXs) 0x007f ) 


if 




error! ) 




if 


(us==s) 
error! ) 




if 


(s!=us) 
error! ) 




if 


(s<us) 
error! ) 




if 


(s>us) 
error! ) 





/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z01.80 



Number: D200080366 Product: 6809 C 64822 01.08 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 

Is incorrect. 

The wording should imply that the conversion should be going the other w 

ay, from real to unsigned integer. 

To get the error: 
,. c „ 

"68000" 

unsigned int a; 

main! ) 

{ 

a=0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 



SRB detail reports as of 09/01/88 
Signed off 01/14/88 in release Z01.80 



Page: 



33 



SRB detail reports as of 09/01/88 
Number: D200063719 Product: 6809 PASCAL 
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64813 
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01. 10 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 

"processor" 

PROGRAM BAD_DATA; 

TYPE EVENT = RECORD 



A 


BYTE; 


B 


BYTE; 


C 


INTEGER 


D 
D; 


BYTE; 



VAR EVENT 1 



EVENT ; 



EVENT(O); { THIS ASSIGNMENT RESULTS IN BAD DATA } 



PROCEDURE GENERATOR! 
BEGIN 

EVENT 1 
END; 

BEGIN 
END. 

Temporary solution: 
No temporary solution. 

Signed off 01/14/88 in release Z01.60 



Number: D2000759U Product: 6809 PASCAL 



64813 



01. 11 



One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

SEXTENSIONS 0N$ 

PROGRAM D0L00P; 

VAR 



SECTORNUM , STOPSECTOR 

A 



UNSIGNED, 
INTEGER; 



SRB detail reports as of 09/01/88 

BEGIN 

STOPSECTOR : = UNSIGNED_8(247) ; 

FOR SECTORNUM :- UNSIGNED_8 (0 ) TO STOPSECTOR DO BEGIN 
A :- 5; 

END; 
END. 
Temporary solution: 

USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 

■PROCESSOR" 

SEXTENSIONS 0N$ 

PROGRAM D0L00P; 

VAR SECTORNUM, STOPSECTOR : UNSIGNED_16; 
A : INTEGER; 
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BEGIN 



STOPSECTOR := UNSIGNED_16(247) ; 

FOR SECTORNUM := UNSIGNED_16(0 ) TO STOPSECTOR DO BEGIN 

A := 5; 
END; 
END. 

This works for values up to 8000H. 
Signed off 01/14/88 in release Z01.60 



Number: D200079186 Product: 6809 PASCAL 



64813 



01.11 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 
changes physical size), when it should generate a fatal error. It 

- -8 
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tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 

"PASCAL" PREPR0CESS 

"6809" 

{ Test program to demonstrate Pascal language defect } 

{ Functional type change of constant to multi-byte variable } 

PROGRAM PTEST101; 
$EXTENSIONS 0N$ 
TYPE event = RECORD 

type : BYTE; 
qualifier: BYTE; 
msg : INTEGER; 
send_task: BYTE; 
END; 
VAR event 1: event; 
i: INTEGER; 
R: REAL; 

BEGIN 

{The following code is attempting to initialize} 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 



eventl 



event (0) 



{This code is incorrect Pascal} 



{Correct Pascal using individual assignments} 

eventl. type: =0; 

eventl. qualifier: =0; 

eventl. msg: =0 ; 

event 1 . send_task : =0 ; 
END. 



Signed off 01/14/88 in release Z01.60 



Number: D200079244 Product: 6809 PASCAL 
Keywords: PASS 1 



64813 



01.11 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 



SRB detail reports as of 09/01/88 

IEXTENSIONS 0N$ 
PROGRAM PTEST; 
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VAR 

S8 
U8 
S16 
U16 

BEGIN 
U16 
U16 



END. 



S16 
S16 



SIGNED_8 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 



UNSIGNED_16(S8) 
UNSIGNED_8(S8) ; 

SIGNED_16(U8) ; 
SIGNED_8(U8) ; 



(* signed extension of S8 - correct *) 

(* signed extension of S8 - incorrect *) 

(* unsigned extension of U8 - correct *) 

(* unsigned extention of U8 - incorrect *) 



Signed off 01/14/88 in release Z01.60 



- -8 
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Number: D200068825 Product: 80286B ASSEMB 
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01.02 



One-line description: 

Assembling on 64100 & linking on VAX generates erroneous absolute file 

Problem: 

If all programs are assembled and linked on the VAX and then downloaded 
to the 64100, the execution in the emulator is fine. But if the monitor 
is assembled on the 64100 and uploaded where it is linked on the VAX and 
downloded back to the 64100, the program runs off in the weeds. 

Temporary solution: 

There is no known work around at this time. 

Signed off 01/14/88 in release Z01.30 



-0 
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Number: D200063909 Product: 8085 B PASCAL 
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01.03 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 



"processor" 




PROGRAM BAD_DATA; 


TYPE EVENT = 
A 
B 
C 
D 
END; 


■ RECORD 
BYTE; 
BYTE; 
INTEGER; 
BYTE; 


VAR EVENT 1 


: EVENT; 



PROCEDURE GENERATOR ( ) ; 
BEGIN 

EVENT1 := EVENT(O); { THIS ASSIGNMENT RESULTS IN BAD DATA } 
END; 

BEGIN 
END. 

Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z01.90 



Number: D200064212 Product: 8085 B PASCAL 
Keywords: PASS 2 



64825 



01.03 



One-line description: 

Incorrect code generated when set elements are passed as parameters. 

Problem: 

Incorrect code is generated when sets are passed as parameters. 
The stack pointer is manipulated so that the program "goes in the 
weeds" after the call to the procedure. The following code is 
an example: 

"processor name" 
$SEPARATE 0N$ 
$EXTENSIONS 0N$ 
TYPE 

Letters = (a,b,c,d,e, f ,g,h, i, j,k,l,m,n,o,r) ; 

Set_of_Letters - SET OF Letters; 
$GL0BPR0C 0N$ 
PROCEDURE Letters_Pas(Received:Set_of_Letters) :EXTERNAL; 

- -0 
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PROCEDURE Init_Set; 
BEGIN 

Letters_Pas( [] ) ; 
END; 
SGLOBPR0C 0FF$ 



*Code generates an extra INC SP after the 
call to Letters Pas*) 



Temporary solution: 

Any set size other than 3 bytes will work correctly. 

Signed off 01/14/88 in release Z01.90 



Number: D200076109 Product: 8085 B PASCAL 



64825 



01.04 



One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

$EXTENSIONS 0N$ 

PROGRAM D0L00P; 

VAR SECTORNUM.STOPSECTOR : UNSIGNED_8; 
A : INTEGER; 

BEGIN 

STOPSECTOR := UNSIGNED_8(247) ; 

FOR SECTORNUM := UNSIGNED_8(0 ) TO STOPSECTOR DO BEGIN 

A := 5; 

END; 

END. 

Temporary solution: 

USE AN UNSIGNED 16 FOR THE CONTROLLING VAR. 



"PROCESSOR" 
SEXTENSIONS 0N$ 
PROGRAM DOLOOP; 



VAR 



SECTORNUM , STOPSECTOR 
A 



UNSIGNED_16; 
INTEGER; 
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BEGIN 



END. 



STOPSECTOR := UNSIGNED_16(247) ; 

FOR SECTORNUM :- UNSIGNED_16 (0 ) TO STOPSECTOR DO BEGIN 

A := 5; 
END; 



This works for values up to 8000H. 
Signed off 01/14/88 in release Z01.90 



Number: D200079228 Product: 8085 B PASCAL 



64825 



01.04 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 

changes physical size), when it should generate a fatal error. It 

tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 

"PASCAL" PREPR0CESS 
"6809" 

{ Test program to demonstrate Pascal language defect } 
{ Functional type change of constant to multi-byte variable } 
PROGRAM PTEST101; 
$EXTENSI0NS 0N$ 
TYPE event = RECORD 

type : BYTE; 
qualifier: BYTE; 
msg : INTEGER; 
send_task: BYTE; 
END; 
VAR event 1: event; 
i: INTEGER; 
R: REAL; 

- -0 
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{The following code is attempting to initialize} 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 

eventl := event(O); {This code is incorrect Pascal} 



{Correct Pascal using individual assignments} 

eventl. type: =0 ; 

event l.qual if ier:=0; 

eventl. msg: =0 ; 

event 1 . send_task : =0 ; 
END. 



Signed off 01/14/88 in release Z01.90 
Number: D200079285 Product: 8085 B PASCAL 
Keywords: PASS 1 



64825 



01.04 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 



SEXTENSIONS 0N$ 
PROGRAM PTEST; 



VAR 



S8 
U8 
S16 
U16 



SIGNED_8 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 



BEGIN 

U16 := UNSIGNED_16(S8): 
U16 := UNSIGNED_8(S8); 



(* signed extension of S3 - correct *) 
(* signed extension of S8 - incorrect *) 



S16 
S16 



END. 



SIGNED_16(U8) 
SIGNED 8{U8) ; 



(* unsigned extension of U8 
i* unsigned extention of U8 



correct *) 
incorrect *) 



Signed off 01/14/88 in release Z01.90 



SRB detail reports as of 09/01/88 

Number: 5000172742 Product: 8085 C 64826 

Keywords: CODE GENERATOR 

One-line description: 

bad code generated with *pointer++ operation 

Problem: 

The example provided produces the following code: 

*b++ = *c++; 
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LXI 

DAD 

MOV 

I NX 

MOV 

XCHG 

SHLD Dfunc+0002H 

INX H 

XCHG 

LXI 

DAD 

MOV 

INX 

MOV 

LHLD 



H.00002H 

SP 

E,M 

H 

D,M 



H.00002H 

SP /* HL = SP+2 */ 

M,E < — puts address of what b points to + 1 in 

H < — | — address of b, instead of *b++ 

M,D < — | 

Dfunc 



Temporary solution: 

Use $RECURSIVE 0N$ directive, or increment the pointer in a seperate 

operation 

Signed off 01/14/88 in release Z02.10 

Number: 5000202846 Product: 8085 C 64826 01.04 

Keywords: CODE GENERATOR 

One-line description: 

> = does not work with float type 

Problem: 

Comparison of real numbers using "less than or equal" (LEQ) libraries 

may fail. 

Temporary solution: 

Break the comparison into two separate tests 



Signed off 01/14/88 in release Z02.10 



Number: 5000220186 Product: 8085 C 
Keywords: CODE GENERATOR 



64826 



01.04 



One-line description: 

When subtract an integer from a pointer, get unnecessary warning message 

- -0 
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Problem: 

Unnecessary warning message is given when subtracting an integer from 

a pointer. 

Example: 

"C" 

"8085" 

unsigned short var,*ptr; 

main! ) 

{ 

var=(*(ptr - 1)); 
} 

this generates an unnessary message about the pointer and the integer 
not being the same size 

Temporary solution: 

A workaround is to add a negative integer and no warning message win 

be generated. Example var=(*(ptr + -1)). 



Signed off 01/14/88 in release Z02.10 



Number: D200068403 Product: 8085 C 



64826 



01.03 



One-line description: 

Expression used as array index generates incorrect code. 

Problem: 

Incorrect code is generated if an array index is an expression of 
the form [i+1] for example. The following program demonstrates 
the problem: 

"C" 

"8085" 

SRECURSIVE 0FF$ 

$SEPARATE 0N$ 

SEXTENSI0NS 0N$ 

$INIT_ZEROES 0FF$ 

#define number_of pages 100 

int program page[T; 

delete_pageTpage_number) 

int page number; 

{ 

int i,j; 

for (i=page number; i < (number of pages - 2); ++i) 
{ 

program_page[i] = program_page[i+l] ; (*This statement causes the 
} problem*) 



The code generated by the assignment statement is 

(*???*) 



LXI 
DAD 
DAD 



D, Istatic 
H 

D 
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SHLD 


Ddelete page+0004H 


LHLD 


Ddelete page 


I NX 


H 


LXI 


D.Istatic (*???*) 


DAD 


H 


DAD 


D 


MOV 


E,M 


I NX 


H 


MOV 


D,M 


LHLD 


Ddelete page+0004H 


MOV 


E,M 


INX 


H 


MOV 


D,M 



Temporary solution: 

Use a temporary variable as the array index: 

delete_page(page_number) 

int page number; 

{ 

int i,j; 

for (i ■ page_number; i < (number_of_pages - 2); 

j + i + 1; 

program_page[i] ■ program_page[ j] ; 

> 

Signed off 01/14/88 in release Z02.10 



-i) 



Number: D200076919 Product: 8085 C 



64826 



01.04 



One-line description: 

Array is being placed in the PROG section rather than data. 

Problem: 

Compiler puts array that should be in DATA section in PROG section 

Example: 

"C" 

"Z80" 

char array[12]; 

The above code when compiled creates an array of twelve bytes that will 
reside in the PROG section. This should be placed in the DATA section. 

Temporary solution: 

Generate an ASM_FILE and edit the ASMProcessor file to place 

the array under the DATA counter. 

Signed off 01/14/88 in release 202.10 



SRB detail reports as of 09/01/88 
Number: D200077263 Product: 8085 C 
Keywords: CODE GENERATOR 



64826 
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One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088" 

main( ) 

{ 

double xx ; 

xx = 2.0/3.0; 

xx = 2.0; 
} 
xx is assigned the value 2.0 by both statements. 

This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 

xx = 2.0/y; where y - 3.0; 

Signed off 01/14/88 in release Z02.10 



Number: D200079087 Product: 8085 C 
Keywords: CODE GENERATOR 



64826 



01.04 



One-line description: 

+ =, "=. *", & /- may fail to auto vars with $RECURSIVE 0N$ 

Problem: 

Composite assignment operators may fail to automatic variables when 

$RECURSIVE 0N$ is in effect. 

The following program segment illustrates this problem. 

"C" 

"8085" 

$RECURSIVE 0N$ 

functil, i2,doub) 
int il,i2; 
double doub; 
{ 

int answer; 

answer = 1 ; 

answer +■ i2*x; /* after this statement answer still is 1 */ 
/* however il = i2 * x */ 



- -0 
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Temporary solution: 

There is no known fix at this time. 

Signed off 01/14/88 in release 202.10 
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Number: D200079160 Product: 8085 C 
Keywords: PASS 1 



64826 



01.04 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 

Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 

$SHORT_ARITH 0FF$ 

short s; 

unsigned short us; 

main( ) 

{ 



if Us/usroxffff) 

error!) : 
if UusXs) 0x007f) 

error! " 
if (us==s) 

error! ) ; 
if (s!=us) 

error! ) 
if (s<us) 

error! ) 
if (s>us) 

error! ) 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z02.10 



Number: D200080382 Product: 8085 C 64826 01.04 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 



SRB detail reports as of 09/01/88 

"C" 

"68000" 

unsigned int a; 

main! ) 

{ 

a=0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 

Signed off 01/14/88 in release Z02.10 
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- -0 
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Number: 5000152918 Product: 8085 EMULATION 
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01.06 



One-line description: 

Can't use 9.5" paper to print mem map, due to centering of printout. 

Signed off 01/14/88 in release Z01.07 



-0 



SRB detail reports as of 09/01/88 

Number: 1650004598 Product: 8086/8 ASSEMB 

One-line description: 

Wrong values during EQU from externals. 



64853 



Page: 50 

02.01 



Problem: 

The 8086 assembler assigns wrong values during equ from externals. 

Following program will show the bug : 

ext al,a2 (assigned somwhere else e.g. to 1 and 2] 
x equ a2 

here the value of al is assigned to x !!!! 

Temporary solution: 

No known workaround at this time. 

Signed off 01/14/88 in release A02.70 



Number: 1650013235 Product: 8086/8 ASSEMB 



64853 



02.03 



One-line description: 

Tabs in source file are expanded to 6 spaces instead of 8 spaces 

Problem: 

The first tab encountered in the source code is expanded 
to 6 characters instead of the expected 8 blanks, causing 
unaligned fields in the assembly listing output. 

Temporary solution: 

Do not put tabs in the source code. 

Signed off 01/14/88 in release 202.70 



Number: 5000136085 Product: 8086/8 ASSEMB 



64853 



02.00 



One-line description: 

Assembler/linker does not correctly handle EQU <EXT_LABEL> statement. 

Problem: 

Temporary solution: 

Don't use the statement 

F001 EQU OFFSET LABI 

Put the address calculation part of the expression in the MOV statement 
something like 

MOV AX, OFFSET LABI 

In other words the EQU statement is not correctly resolved by the 
assembler/linker. 

Signed off 01/14/88 in release Z02.70 



SRB detail reports as of 09/01/88 

Number: 5000170415 Product: 8086/8 ASSEMB 



64853 
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02.03 



One-line description: 

The noload files aren't showing up in the listing; absolute correct 

Problem: 

Noload files are being linked correctly. They do not appear in the 
absolute file. However, the listing shows these files as loaded. 
The expected parenthesis around the no load file is not present. 

Temporary solution: 

No known temporary solution for the listing problem. Emulation 

can verify that the absolute is correct. 

Signed off 01/14/88 in release Z02.70 



Number: 5000172593 Product: 8086/8 ASSEMB 
Keywords: LINKER 



64853 



02.03 



One-line description: 

Label preceeded with WORD PTR,NEAR PTR, etc. will not appear in the xref 

Problem: 

A label which is preceeded by a psuedo like NEAR PTR, WORD PTR, 

etc. does not appear in the assembler's xref in the references 

column. 
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0005 2E8A8C000C 
0OOA 2E8B84000C 
000F 0B1621 

ERRORS' 



5 MOV 

6 MOV 
7FIX DB 



CL,FIX[SI] 

AX, WORD PTR FIX [SI] 

11,22,33 



IN ABOVE PROGRAM, ASSEMBLER DOES NOT COUNT ADDRESS CORRECTRY. 
0O0F SH0UD BE GENERATED. (NOW 000C) 

The address 0C that is used for addressing FIX [SI] points to 
the middle of line 000A. The three addresses 0C should point 
to line 0000F. This is a bug in the most recent SMS. 

Signed off 01/14/88 in release Z02.70 



Number: D200060509 Product: 8086/8 ASSEMB 
Keywords: LINKER 



64853 



02.01 



One-line description: 

Linker generates error if C0MN segment is not 00O0H 

Problem: 

This SR was originally entered under the operating system, SR#5000- 

143487. 



"processor name" 




The linker generates a "Max addr or seg boundry exceed" when the COMN 


1 LABI MOV AW,#0H 




area is used and when its segment is not 0000H. 


2 BZ NEAR PTR LABI 






3 BR LABI 




For Example: Linking a file that uses the COMN psuedo instruction 


4 END 




at 010001000,010002000,010003000, will result in this error. 


Cross Reference table: 




Temporary solution: 

No known temporary solultion. 


LINE# SYMBOL TYPE REFERENCES 






1 LABI P 3 < should also have 2 




Signed off 01/14/88 in release Z02.70 




Number: D200077768 Product: 8086/8 ASSEMB 64853 02.01 


Temporary solution: 






Do xref on the 64100. Problem only occurs on host computers. 




One-line description: 
reusing accumulator 


Signed off 01/14/88 in release Z02.70 




Problem: 


Number: 5000201012 Product: 8086/8 ASSEMB 64853 


02.02 


The AX register is being destroyed: 


Keywords: CODE GENERATOR 




"80186" 
{EXTENSIONS 0N$ 


One-line description: 




{POINTER SIZE=32$ 


Incorrect Object code generated 




{SEPARATE CONST 0FF$ 
PROGRAM CL; 


Problem: 






1 "8086" 




TYPE 


2 ASSUME CS:PR0G 






3 PROG 




U 8 = UNSIGNED 8; 


0000 2E8A84000C 4 MOV AL,FIX[SI] 




U_16 = UNSIGNED_16; 


- -0 




- -0 



SRB detail reports as of 09/01/88 
U_32 = UNSIGNED_32; 
IDS = U_8(0) . .U_8(9) ; 
BASE CLK = RECORD 
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HEAD 
TAIL 
SIZE 
END; 



U_8 
U_8 
U 8 



CLSREC - RECORD 
TOTCNT : U_32; 
Z PAD : ARRAY[U_16(0) . .U_16(500)] OF U_8; 
ND; 



AR 

CLSSR 
CR 



: ARRAY[U_8(0) . .U_8(1),IDS] OF BASE_BLK ; 
: ARRAY [U 8(1)..U 8(48)] OF CLSREC; 



FUNCTION GCNT(ID:IDS):U_16; 

VAR 

CH : U_8; 

BEGIN 

$LIST_C0DE ON$ 

GCNT :■= CR[CLSSR[CH,ID]. HEAD] .TOTCNT; 



MOV 


AL,#+00003H 


MUL 


SS:BYTE PTR [BP+00004H] 


ADD 


BX,AX 


MOV 


AL,DS:BYTE PTR [BX] 


MOV 


AH,#0 


MUL 


AS AX GETS DESTROYED HERE 


ADD 


SI, AX 


MOV 


AX,DS:WORD PTR [SI] 


$LIST CODE 


OFF$ 


END; 





Temporary solution: 

There is no known work around at this time. 

Signed off 01/14/88 in release Z02.70 



Number: D200093377 Product: 8086/8 ASSEMB 
Keywords: PROBLEM ON VAX 



64853 



00.00 



One-line description: 

"PRODUCT # CHANGE on the VAX* From* 64xxxS003 To=64xxxM003 

Problem: 
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This Service Request has been entered to inform users of the product 

THAT: 

The *PR0DUCT NUMBER has CHANGED on the VAX version of this product 

FROM (OLD Product Number)* 64xxxS003 < The real cMnge being 

< the "S" chaiged to "M" 
TO (NEW Product Number) = 64xxxM003 < in this Product Series 

(The "xxx" in the above to be filled in with the Product Number 
against which this SR is entered... This text applies to many 
SR's and is generic in nature.) 

The above event happend without a change to the REVISION CODES on the 
PRODUCT. 

This event happend on the revision code that was used to sign off 
this Service Request. 

Signed off 08/31/88 in release A02.70 
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Number: 5000226613 Product: 8086/8 ASSEMB 300 64853S004 02.20 

Keywords: LINKER 

One-line description: 

Linker can generate invalid DATE on listing file. 

Problem: 

Very infrequently, the linker generates an invalid DATE on the listing 
file. When file are compiled or assembled on 9/01, the DATE file shows 
as 32 Aug 1987. 



FILE/PROG NAME 
boot.R 



PROGRAM DATA COMMON ABSOLUTE DATE TIME 
00000400 TUE, 32 Aug 1987, 



Temporary solution: 

There is no work around at this time. 

Signed off 01/14/88 in release Z02.70 
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Number: D200079335 Product: 8086/8 ASSEMB 

Keywords: CODE GENERATOR 
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One-line description: 

VMS Hosted linker does not recognize logical names 

Problem: 

Detailed Listing for Defect Number LSDqf00689 



Submission Number: 00663LSDqf 
Defect Status: OPEN 
Prod/SCMS:/lsd/pplus/cmd/lnk 
Version : current 
Severity: 1 
Showstopper: No 
Workaround: No 
Defect/Enhancement: 
* defect 



Date Found: 870817 

Date Arrived: 870817 

Date Received: 870820 
Date Resolved: 

Number of Duplicates: 
Additional Files: 1 



lestimated) 



Text: 

VMS hosted linker does not recognize logical names 



Submitter Supplied Information 

Submitter name: Lee Jackson 

Submitter phone: 

Submitter address: lee 

Activity used to find defect: casual use 



Responder Supplied Information 

Responsible site: LSD 
Responsible project: stars 
Responsible engineer: STARS II 



. submitter 



When the linker is given a file name it does not test to see that the 
name is a logical name, thus if the name is a logical name, the linker 
will not open the appropriate file. 

Temporary solution: 

There is no known work around at this time. 

Signed off 01/14/88 in release Z02.70 



SRB detail reports as of 09/01/88 
Number: 1650026708 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 
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One-line description: 

Right shift using var. for # of places to shift generates bad code 

Problem: 

The following program generates incorrect code: 

"C" 
"8086" 

mainU { 
int a; 
unsigned b; 
a = 5 >> b; 

/* negates and then does a left shift instead of a right shift */ 
a = 5 >> 3; 

/* works fine */ 
a = 5 << 3; a = 5 < < b; 

/* both work fine */ 
} 

Temporary solution: 

Manually edit the ASM8086 file, generated using $ASM_FILE$, and 

assemble. 

Signed off 01/14/88 in release Z03.70 



Number: 2700005520 Product: 8086/8 C 
Keywords: RUN-TIME LIBRARY 



64818 



00.00 



One-line description: 

REAL NUMBER COMPARISONS MAY NOT EVALUATE CORRECTLY. 

Problem: 

There is a problem with REAL COMP in the 8086 C real number library 

when mantissas are compared. Real numbers declared as float or double 
do not compare correctly when they differ in the sixth figure. 



double a, b 
a = 12.3456 
b = 12.3455 



/* can also be declared float */ 



if (a > b) 

result = 1; 
else if (a == b) 

result - 0; 
else result = 2: 



/* result - after this code is executed */ 



Temporary solution: 

No known temporary solution at this time. 



SRB detail reports as of 09/01/88 
Signed off 01/14/88 in release Z03.70 
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Number: 5000134593 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



02.01 



One-line description: 

1102 error generated - register needed but not availiable 

Problem: 

The following program generates a 1102 -register needed but not 

available error: 

"C" 

"8086" 

struct test { 
int bbb ; 
short aaa; 
}; 

bbb(ptr) 

struct test *ptr; 
{ 

short x; 

x = ptr -> aaa >> 4; 
} 

ma int ) 
{} 

The assembly code mneumonics generated for the expression, 
x = ptr -> aaa >> 4, included: 

mov cl, #+00004H 

push ex 

mov ch, (some variable) 

pop ex 

shr ch, cl (ch is unknown after the pop) 

This same code was genrated by the Pascal compiler, SR#5000-138388. 

Signed off 01/14/88 in release Z03.70 

Number: 5000134601 Product: 8086/8 C 64818 02.01 

Keywords: CODE GENERATOR 

One-line description: 

Incorrect segment of array transfered to pointer 

Problem: 

ES is used to store the segment of an array but DS is loaded into the 

pointer+2H. 

"C" 

"8086" 

$FAR_EXTVARS$ 

$P0INTER_SIZE 32$ 

extern struct {int a,b[3],c; } ary[5]; 

- -0 



SRB detail reports as of 09/01/88 Page: 59 

int *p, i; 

foolO 

{ p-&ary[i].b[i];} 

MOV AX.SEG ary 

MOV ES.AX {segment of ary in ES} 

MOV DS:W0RD PTR Dstatic+2H,DS {moves incorrect segment into ptr} 

main( ){} 

Temporary solution: 

The following program generates the correct code: 

extern struct Tint a,b[3],c;} *p,ary[5]; 

int *t,i; 

f() { p-&ary[i]; 

t-M*p).b[i];> 

Signed off 01/14/88 in release Z03.70 



Number: 5000136267 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



02.01 



One-line description: 

ES register corrupt when used to get address of array to place in ptr. 

Problem: 

The following program places the incorrect segment of an array 
address into a pointer. 
"C" 

"8086" 

$POINTER_SIZE 32$ 

$FAR_EXTVARS$ 

extern int var [10] [10]; 

extern int *point; 

main( ) { int x,y; 

point » &var[x] [y] ; 
MOV AX,#+0014H 



MOV AX.SEG var 
MOV ES,AX 



{ES contains the segment value of var) 



MOV AX.SEG point 

MOV ES,AX {ES contains the segment value of point) 

MOV ES:W0RD PTR point+00002H,DS {DS is unknown) 
> 

The segment value for var should have been loaded into DS, or PUSH on th 
e stack. 

Temporary solution: 
Temporary solution: 

extern int var [10*10]; 
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extern int *point; 

main ( ) { int x,y; 
int p; 

p= x*10+y; 
point = &var [p] ; 
) 

Signed off 01/14/88 in release Z03.70 

Number: 5000149229 Product: 8086/8 C 64818 03.00 

Keywords: CODE GENERATOR 

One-line description: 

Return statement not putting value on BX register 

Problem: 

In the following program, the code generated for case 4 

does not return a value in the "BX" register. A "12" is 

put in the accumulator, but nothing ever happens to it. 

When the program is getting ready to return we need the 

following command: 

MOV BX,SS:WORD PTR {BP_00008H] 

/*******Sample program***********/ 

"C" "8086" 

$SEPARATE_C0NST 0FF$ {POINTER SIZE=32$ $FAR EXTVARSS 

$FULL_LIST 0FF$ $AMNESIA 0N$ {"EXTENSIONS 0N$~ $INIT_ZEROES 0FF$ 

$FAR_PR0C 0N$ $FAR_LIBRALIES 0N$ 

struct 

{ 

int ino; 
} index [160]; 
splOmainf ) 
{ 

int 1 , c ; 
while(l) { 

switch(c) { 

case 4: return! 12) ; 

case 1: for (1=15; index[ (2*l+c)*16+l] . ino<0 ; 1--) ; 
) 
} 
> 



Temporary solution: 

Breaking up the expression for the array value of index[] 
causes the compiler to generate the correct code. Create 
an "int" type variable: 

int k 
k-(2*l+c)*l6+l 

and use this inside the 'for' loop 



SRB detail reports as of 09/01/88 
Signed off 01/14/88 in release Z03.70 
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Number: 5000149757 Product: 8086/8 C 



64818 



03.02 



One-line description: 

Code generated for illegal C statement - POP BH generated 

Problem: 

The C compiler generates invalid code for the following program. 

"C" 

"80 188" 

$FAR_EXTVARS, P0INTER_SIZE 32$ 

struct Button_def { 

char *(*labels)U; 
}; 

extern struct Button_def Button_List[] ; 

Draw_Button (but ) 
char but; 

{ 

struct Button_Def *but_p; 
char *lab_p[] ; 
char bindex; 

but_p = &Button_List [bindex] ; 
lab_p = *but_p-> labels; 

/♦generates invalid code including a POP BH*/ 
} 

The compiler does not flag an error when a pointer is being assigned 
to a constant address with no memory associated with it. For example, 
lab_p is the name of an array. There is memory allocated for each of 
the array elements (i.e. lab_p[2]), but the name lap_b has no memory 
associated with it. THerefore, you should not be able to write "lab_p 
= whatever". Our compiler, however, attempts to generate code for this 
statement. ( Note that the s/w going out in the October suds generates 
a "60:Lvalue expected" error for this statement). 

Temporary solution: 

One possible way to get the desired results is: 

"C" 

"80188" 

$FAR_EXTVARS, P0INTER_SIZE 32$ 

struct Button Def 

{ char *T*labels)[]; 

); 

extern struct Button_def Button_List [] ; 

Draw_Button(but) 
char but; 

{ struct Button_Def *but_p; 
char **lab_p; 
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char bindex; 

but_p = &Button_List [bindex] ; 
lab_p = *but_p-> labels; 
} 

labels is a ptr to an array of ptrs. to chars. 
lab_p is now a ptr to a ptr to chars. 

These two can now be equated. 

Signed off 01/14/88 in release Z03.70 

Number: 5000149765 Product: 8086/8 C 64818 03.02 

One-line description: 

Address of array element incorrectly calculated 

Problem: 

The following program causes the processor to go into the weeds. 

"C" 

"80188" 

$FAR_EXTVARS, P0INTER_SIZE 32$ 

struct Button_0bj { 

char butxl, butyl, butx2, buty2; 

char button_code, label_code; 

char button parm, button_attrib; } ; 
#define diasable_blt 0x08 
extern int Button; 

extern struct Button_0bj Current_Buttons[] ; 
extern char obj_index; 

State_Machine( ) { 
char B_code; 
int Error; 

if ( Button != OxFFFF) 
{ 
SMI: obj_index = ( Button & OxFF ); 
Button = OxFFFF; 

if ((Current Buttons[obj index] .button attrib & disable bit) = 
= 0) 
{ } 
} 
} 

The code generated for the last if statement looks like: 
MOV AX.SEG obj_index 
MOV ES,AX 

MOV BL,ES:BYTE PTR obj_index 
MOV BH, #0 
SHL BX,#+00003H 
MOV AX.SEG Current_Buttons 
MOV ES,AX 

MOV AL, ES:BYTE PTR Current_Buttons[BX+07H] 
etc. 
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WHen tracing the emulation the same statement as NOV AL,ES:BYTE PTR 
Current_Buttons[BX+07H] becomes BX+08H. 
This may be incorrect. 

The program was loaded at 1000h,2000h,3000h. The monitor was loaded at 
4000H,5000H,6000h. 

The second file consists of : 

"C" 

••80188" 

"$FAR_EXTVARS, POINTER_SIZE 32$ 

struct ButtonJDbj { 



Temporary solution: 

No known temporary solution. 

Signed off 01/14/88 in release Z03.70 



Number: 5000162487 Product: 8086/8 C 64818 03.02 

Keywords: CODE GENERATOR 

One-line description: 

Vax not creating same code as the 64000 

Problem: 

8086 C compiler rev 3.4 on Vax does not create the same code as the comp 
iler on the 64000. The code on the 64000 is correct. The code on the 
VAX is not. 

"C" 64000 creates the following VAX creates these: 

"8086" for both assignment statements: 

#$LIST_C0DE$ LEA SI ,DS: C0NST_data <= that for the temp=0.5 

#$LIST 0N$ LEA DI 

testO; . this for the 1.0/2.0 

{ . LEA SI,DS:C0NST_data+0008H 

double temp; 

temp=0.5; DATA 

temp=l. 0/2.0; C0NST_data 

} DB OO0H,000H,00OH,O00H DB OO0H.O00H, 000H.000H 
0O0H.OO0H.0E0H.03FH 000H,000H,0E0H,03FH 

Temporary solution: 

There is no known work around at this time. 

Signed off 01/14/88 in release Z03.70 

- -0 
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Number: 5000163410 Product: 8086/8 C 
Keywords: PASS 1 



64818 



03.02 



One-line description: 

compiler using DS segment rather than ES segment for 32 bit pointers 

Problem: 

When 32 bit pointers are used with structures the DS segment is moved 

rather than the ES segment. This occurs if arithmatic is done in a 

parentehsis. 

EXAMPLE: 

"C" 

"80186" 

$POINTER_SIZE 32$ 
$FAR_EXTVARS 0N$ 

struct cmd_exe_struct{ 
int test; 

int opt parms[16] ; 
}; 

extern struct cmd_exe_struct cmd_exe[]; 

ma int ) 

{ 

int dev,*ptr; 

ptr - cmd exe[dev-l] .opt_parms; 

} 

Temporary solution: 

Assign arithmatic operations within parenthesis to a temporary 

variable. 

Signed off 01/14/88 in release Z03.70 

Number: 5000165134 Product: 8086/8 C 64818 03.02 

Keywords: CODE GENERATOR 

One-line description: 

BX register overwritten with a switch statement 

Problem: 

The following program causes the BX register to be overwritten while 

calculating the index of the array. 

"C" 

"80188" 

$EXTENSIONS ON$ 
$FAR_EXTVARS$ 
$POINTER SIZE=32$ 
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extern char Channel_Data[6] [9] , SelectedTrace, SIchnl_type; 
#define ECG 
#define SI_ECG_btns 
char btns; 

SI channel_se 1 ( chn l_type , chnl- index ) 

char chnl type, chnl index; 
{ 
switch (Channel_Data[SelectedTrace] [SIchnl_type] ) 

i'.jV AL,#+00009H 

MOV CS,SEG SelectedTrace 

MOV ES,CX 

MUL ES:BYTE PTR SelectedTrace 

MOV BX.AX 

LEA BX,DS:Channel_Data[3X] puts address of Channel_Data in BX 



MOV BL,ES:BYTE PTR SIchnlJType reuses BX - Channel_Data address 
MOV BH,#0 lost!!! 

ADD BX.BX 



case(ECG) : 

btns = SI_ECG_btns; 
break; 



Temporary solution: 

There is no known work around at this time. 

Signed off 01/14/88 in release Z03.70 



Number: 5000172239 Product: 8086/8 C 



64818 



03.02 



One-line description: 

external used 2x in same pgm, w/ ASM_FILE ON, get 2 EXT stmts in ASMfile 

Problem: 

The following C program, when, using ASM_FILE ON, puts 2 EXTERNAL 

zzz statements, and then the ASM70108 file will not assemble. 

"C" 

"8086" 

$ASM_FILE 0N$ 

b() 

{ 

extern zzz; 

} 

c() 
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{ 

extern zzz; 

} 

The ASM70108 file looks like this: 

"70108" 

; 1 0000 "C" 

EXTERNAL zzz 

EXTERNAL zzz 
" ERROR-ET 

ET - Expression Type 
07/24/87 LSD STARS DTS LINK 
07/24/87 LSD STARS DTS LINK 
07/24/87 LSD STARS DTS LINK 

Temporary solution: 

No known solution at this time. 



Signed off 01/14/88 in release Z03.70 
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COPIED TO D200078766 64818 
COPIED TO D200078774 64818S001 
COPIED TO D200078782 64818S004 



Number: 5000186718 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.01 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088" 

main( ) 

{ 

double xx ; 

xx - 2.0/3.0; 

xx = 2.0; 
} 
xx is assigned the value 2.0 by both statements. 

This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 

xx = 2.0/y; where y = 3.0; 

Signed off 01/14/88 in release Z03.70 



Number: 5000193466 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.01 



One-line description: 

When using calculated value for array index, uses BX register twice 



- -0 
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Problem: 

When compiling the next source, compiler generates incorrect codes. 

"C" 

"8086" 

$FAR EXTVARS$ $POINTER SIZE-32S 

$FAR LIBRARIES+$ $SEPARATE C0NST+$ 

extern long CP0S[4] ,PCMDTBL[6] [50] [8] ; 

main( ) { int stepno; 

stepno-1; 

PCMDTBL[0] [stepno-1] [1]=CP0S[1] ; } 






The assembler listing file is as follows. 




LES BX,SS:DWORD PTR[BP-00006H] (1) 

MOV BX.SEG PCMDTBL (2) 

MOV ES.BX (3) 

POP ES: [BX+00004H] 

POP ES: [BX+00006H] 
} END OF 1/2 
Compiler sets the offset address of PCMDTBL[0] [stepno-1] [1] to BX 


END OF 2/2 

Temporary solution: 

No know solution at this time. 

Signed off 01/14/88 in release Z03.70 


register (lined) ) . 

But BX register is set the segment address of PCMDTBL at line (2). 

Temporary solution is as follows. 


Number: 5000195628 Product: 8086/8 C 64818 03.01 

One-line description: 

ES reg overwritten when assign char array to complex data structure 


int stepno, X; 

stepno=l; 

X=stepno-l; 

PCMDTBL[0] [X][1]=CP0S[1]; 


Problem: 

When the submitted text was compiled with version 3.70 of 
the 8086 C Compiler the results were correct. However, new 
source was sent that produced the original error: 


END OF 2/2 
8086 C generates incorrect codes. 
Array's address isn't correct. 


"C" 

"8086" 

SOPTIMIZE 0FF$ 
$FIXED PARAMETERS 0N$ 
$EXTENSIONS 0N$ 
$FAR LIBRARIES 0N$ 
$FAR PROC 0N$ 
$P0INTER SIZE 32$ 
$SEPARATE CONST OFF$ 
$RECURSIVE 0N$ 
$LIST_C0DE 0N$ 




#define artex len 20 
#define mask_80 7FH 




struct SET1 { 

int dummy; 

char ART TEXT [64]; 
} 


END OF 1/2 
Please refer to the verifier text No. 1/2. 


struct SET2 { 

int dummy 1; 

int dummy2; 

char ARTTEXT[64]; 
} 


- -0 


- -0 



SRB detail reports as of 09/01/88 Page: 69 

function! ) 
{ 

struct SET1 *P6; 
struct SET2 *P7; 

for (I=0;I<artex len;I++) 
{ 
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reinitialized inbetween uses. 

Temporary solution: 
Create ASM file and modify 

Signed off 01/14/88 in release Z03.70 


P6->ART TEXT [I] = P7->ARTTEXT[I] 1 (P6->ART TEXT [I] & mask 80] 
} 
} 

Version 3.70 of the C Compiler did indeed generate incorrect code. 
The ES segment was loaded using LES when accessing P7, and ES was 
never re-assigned before loading the value into P6. 

However, version 3.80 saved the value loaded into ES from P6, and 
re-assigned ES before after accessing P7. Therefore, I believe 
3.80 fixed this SR. 

Temporary solution: 

Use an array name instead of a pointer. 

Signed off 01/14/88 in release Z03.70 


Number: 5000203596 Product: 8086/8 C 64818 03.30 

Keywords: CODE GENERATOR 

One-line description: 

Problem w/ unreleased Rev. Dx Register destroyed 

Problem: 

DX register using temporary data buffer was destroyed by calculateing 

the address of external variable, before using this temporary data. 

example: 

func ( lnc in , lncout ) 

unsigned short lncin; 
unsigned short lncout; 

struct tgcntb { 


Number: 5000201749 Product: 8086/8 C 64818 03.20 

Keywords: CODE GENERATOR 

One-line description: 
compiler reusing CX register 

Problem: 

This program causes the CX register to be used twice, without being 

reintialized in between uses. 

"C" 
•■8086" 

struct struct3 {char elel; char ele2; char ele3;}; 

struct struct8 {char elel; char ele2; char ele3; char ele4; char ele5; 
char ele6; char ele7; char ele8;}; 

func ( ) 
{ 

char c; 

int i; 

struct struct8 (*src)[100]; 
struct struct3 (*dest)[4]; 


{ char *cinpa, 
*couta; 
unsigned int cinpb 
coutb; 
} 
extern struct centb[8] ; 
extern unsigned int centp.centc; 

if (centc < 8) 
$0PTIMIZE 0FF$ 

{ 
$0PTIMIZE 0N$ 

centb[centp] . cinpb=lncin; 
centb[centp] . coutb=lncout ; 

MOV DX,SS:W0RD PTR [BP+00012H] 

MOV AX,#+0000CH 

MOV DX.SEG centp ; DX IS DESTROY 

Temporary solution: 

There is no know work around at this time. 

Signed off 01/14/88 in release Z03.70 


c=(*src) [i] .ele3; 
(*dest) [i] .ele2=c; 

- -0 


Number: 5000216036 Product: 8086/8 C 64818 03.10 

Keywords: LINKER 

One-line description: 

The noload files aren't showing up in the listing, absolute correct 

- -0 
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Problem: 

Noload files are being linked correctly. They do not appear in the 
absolute file. However, the listing shows these files as loaded. 
The expected parenthesis around the no load file is not present. 
This problem is also found on the Series 300 

Temporary solution: 

There is no known solution at this time. 

Signed off 01/14/88 in release Z03.70 



Number: 5000223800 Product: 8086/8 C 
Keywords: CODE GENERATOR 



$4818 



03.02 



One-line description: 

Bad code generated for address of external character if for loop 

Problem: 

The following program generated code that did not reference the 

external variable correctly: 



"C" 

"8086" 

$FAR_PR0C 0N$ $FAR_LIBRARIES 0N$ $P0INTER SIZE =32$ 

$SEPARATE_C0NST 0FF$ $INIT_ZER0ES 0FF$ ¥FAR_EXTVARS 0N$ 

extern char ** DISPJ2; 

extern char ** DISPJ2end; 

char *dme ; 
int table_set (japan) 
int japan; 



{ 



char **cpl,**cp2; 
if (japan) { 

for(cpl=&dme,cp2=&DISPJ2; cp2 < &DISPJ2end ;] 
*cpl++ =*cp2++; 
} 
} 

The comiler should have pushed ES, instead of DS. 

Temporary solution: 

Use a temporary varible buf, to hold &DISPJ2end: 

char **cpl,**cp2; 

char ***buf; buf=&DISPJ2end; 

if (japan) { 

for (cpl=&dme,cp2=&DISPJ2;cp2 < buf) 

Signed off 01/14/88 in release Z03.70 
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Number: 5000229476 Product: 8086/8 C 
Keywords: SF1001 
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One-line description: 

When casting unsigned ints to floats using +-, generates a error #1001 

Problem: 

Program generates error #1001 when using summation "+=" and casting 

the result of a multiplication of 2 unsigned integers into a double. 



"8086" 

"C" 

unsigned int b[2](5] = { {1, 1, 1, 1, 

unsigned int a[5] - {1, 1, 1, 1, 1}; 

double x; 

int CNTR 

int XPIX 

ma int ) 



for (CNTR=0;CNTR=4;++CNTR) 

x += b[CNTR] [XPIX] * atCNTR]; 



1},{1, 1, 1, 1, 1> }; 



} 
THIS GENERATES AN ERROR 



#1001 



Temporary solution: 

Use: 

x = x + b[CNTR] [XPIX] * a[CNTR] 

or cast the right side of the equation into a float 

Signed off 01/14/88 in release Z03.70 

Number: D200025858 Product: 8086/8 C 64818 01.06 

Keywords: CODE GENERATOR 

One-line description: 

Argument to switch statement may be doubled. 

Problem: 

Switching on a dereferenced pointer to a structure field or on a multi- 
dimensional array field generates incorrect code which doubles the 
switch argument. The following is an example of this: 

"C" 

"PROCESSOR NAME" 

unsigned short i; 

struct { short z; short y[]; } *x; 

main() { 

i = 1; 

switchlx -> y[i]) { /'Generates code which doubles the argument*/ 
case 0: break; 



} 



} 



- -0 
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Temporary solution: 

Set up a temporary variable of the appropriate type and assign the 

expression to it. Use the temporary in the switch statement: 

int temp; 
temp = x -> y[i] ; 
switch (temp) { 
. . . } 

Signed off 01/14/88 in release Z03.70 



Number: D200031476 Product: 8086/8 C 



64818 



02.00 



One-line description: 

Using a postfix decrement operator in a conditional statement fails. 

Problem: 

Using a postfix decrement operator in a conditional statement generates 
an incorrect comparison. When a value is supposed to be compared to 
zero, it is instead compared to -1. If the value is declared unsigned 
then this will never be true. The following code is an example: 

"C" 

"processor name" 
unsigned short i,j; 
char s[20] ,d[20] ; 
mainO { 

J ■ 10; 

for (i - 0; j — ; s[i++] - d[j]); /*compares j to -1, which it will 
} never be*/ 

The order of evaluation of the decrement operator is also incorrect, 
which is documented in SR #D200-031294. 

Temporary solution: 

Rearrange the expression so that the postfix decrement operator is not 

used: 

for (i = 0; j; s[i++] = d[— j]); 

Signed off 01/14/88 in release Z03.70 

Number: D200042606 Product: 8086/8 C 64818 02.00 

One-line description: 

Compiler uses wrong segment register. 

Problem: 

In the following example, the compiler forgets which segment register 

to use after several expressions involving pointers. 



"processor name" 

$P0INTER_SIZE=32$ 

test!) 

{ 

int *p,*q,i, j; 
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j-*(p+l); 

i=*p; 

q=p+2; /*listing looks like this: 
ADD BX,#+04H 

MOV SS:W0RD PTR [BP-00008H] ,BX 
MOV SS:W0RD PTR [BP-00006H] ,DS 

"should be ES */ 



Temporary solution: 

Turn $AMNESIA 0N$ around that expression. 



Signed off 01/14/88 in release Z03.70 



Number: D200049916 Product: 8086/8 C 



64818 



03.00 



One-line description: 

DX register is used although it is overwritten by IMUL instruction 

Problem: 

The value of the DX register is incorrect because it has been 

destructed by the IMUL instruction. 

Example: 

struct { 

char dummy 1; 
int varl; 
} block [12]; 
ROUT I NE ( par ami , param2 ) 
int paraml; 
long param2; 
{ 
block [paraml] .varl = param2 /0xl0000; 

IMUL SS:W0RD PTR [BP+00008H] 
MOV SI, AX 

mov ES:W0RD PTR [SI-00FFFH] ,DX ; DX has been overwritten 

; by IMUL 

return; 



Temporary solution: 

No known temporaray solution. 

Signed off 01/14/88 in release Z03.70 



Number: D200057802 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.00 



One-line description: 

Nonsense code generated by dynamic struc declaration in a funct. 



Problem: 



- -0 
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Dynamic data structures which access an array element of an unknown 
sized array cause the compiler to generate bad code. 

Temporary solution: 

No known solution at this time. 

Signed off 01/14/88 in release Z03.70 



Number: D200068684 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.01 



One-line description: 

Compile incorrect when a ptr to an int is casted as a short and incremen 

Problem: 

The following table describes the compiled files and their results 

on 64100. 



Number of increment 

test "if" Ptr increments; and gets 

case used size statemnt separate 

separation statements 



BUG DESCRIPTION 



TEST1 


yes 


32 


2 


TEST2 


no 


32 


2 


TEST3 


yes 


32 


2 


TEST4 


yes 


16 


2 


TEST5 


no 


16 


2 


TEST5 


yes 


16 


2 


TEST7 


yes 


32 


1 


TEST8 


yes 


16 


1 


TEST9 


no 


32 


1 


TEST10 


no 


16 


1 


TESTU 


no 


32 


1 


TEST12 


no 


16 


1 



no 


Reboot 


no 


No inc 


no 


No inc 


no 


Reboot 


no 


compi 


no 


Reboot 


no 


No inc 


no 


Reboot 


yes 


error 


yes 


error 


yes 


No inc 


yes 


No inc 



s system 

rements in listing 

rements in listing 

s system 

les correctly 

s system 

rements in listing 

s system 

in factor message 

in factor message 

rements in listing 

rements in listing 



Temporary solution: 

No known temporary solution. 

Signed off 01/14/88 in release Z03.70 



Number: D200070532 Product: 8086/8 C 64818 03.02 

Keywords: CODE GENERATOR 

One-line description: 

Incorrect segment passed to external function 

Problem: 

The compiler passes the incorrect segment to an external function. 

"C" 
"8088" 

#define ushort unsigned short 
#define uint unsigned 

- -0 
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$POINTER_SIZE 32$ 
$FAR_EXTVARS$ 
$INIT_ZEROES OFF$ 
$SEPARATE_CONST 0FF$ 
$FAR_LIBRARIES 0N$ 
$FAR_PR0C 0N$ 
SENTRY 0FF$ 

extern char m[2] [4] [8]; 
extern ushort a[5] ; 
extern movb( ) ; 

char *p; 

proc(ptr,num) 
char *ptr; 
uint num; 
{ uint r,j,k; 

movb( m[k] [r] ) ; 

/* MOV CL,#+00005H 

MOV BX,SS:W0RD PTR [BP-00002H] 

SHL BX,CL 

LEA BX,DS:m[BX] 

MOV AX.SEG m 

MOV ES.AX 
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PUSH DS 

PUSH BX 

CALL FAR PTR movb 

: */ 



offset loaded into bx 
segment for m into ES 

not ES 



DS passed to movb 
WRONG 



This problem occurs on version 3.20 of the compiler. ES should have 
been pushed on the stack instead of DS. 

Signed off 01/14/88 in release Z03.70 

Number: D200070615 Product: 8086/8 C 64818 03.01 

Keywords: CODE GENERATOR 

One-line description: 

Incorrect segment passed to external function 

Problem: 

The compiler passes the incorrect segment to an external function. 

"C" 

"8088" 

ttdefine ushort unsigned short 
ttdefine uint unsigned 



- -0 



SRB detail reports as of 09/01/88 

$POINTER_SIZE 32$ 
$FAR_EXTVARS$ 
$INIT_ZEROES 0FF$ 
$SEPARATE_CONST 0FF$ 
$FAR_LIBRARIES 0N$ 
$FAR_PR0C 0N$ 
SENTRY 0FF$ 

extern char m[2][4][8]; 
extern ushort a[5] ; 
extern movb( ) ; 

char *p; 

proc(ptr,num) 
char *ptr; 
uint num; 
{ uint r,j,k; 

movb( m[k] [r] ) ; 

/* MOV CL,#+00005H 

MOV BX,SS:W0RD PTR [BP-00002H] 

SHL BX.CL 

LEA BX,DS:m[BX] 

MOV AX.SEG m 

MOV ES.AX 
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offset loaded into bx 
segment for m into ES 



PUSH DS 

PUSH BX 

CALL FAR PTR movb 

: */ 



DS passed to movb() not ES 
WRONG 



This problem occurs on version 3.20 of the compiler. ES should have 
been pushed on the stack instead of DS. 

Signed off 01/14/88 in release Z03.70 



Number: D200072371 Product: 8086/8 C 
Keywords: CODE GENERATOR 



64818 



03.01 



One-line description: 

Assignment to ptr var. (w/ Separate_const off) causes corrupt stack 

Problem: 

The following program generates an incorrect number of PUSH'S 

and POP's. The problem did not occur on rev. 3.01. 

"C" 
■'8086" 

$POINTER_SIZE 16$ /* pointer_size 32 has this problem also */ 
$SEPARATE_CONST 0FF$ /* required for problem to occur */ 
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main () 

{ double *a; 
*a++ - 0.0; 

/* MOV AX,SS:W0RD PTR [BP-00002H] 

ADD SS:W0RD PTR [BP-00002H] ,#+00008H 

LEA SI,DS:Const_prog 

PUSH DS - saves the value of ds 

missing a PUSH CS here to set up for the M0VSB 

MOV BX,AX 

LEA DI.DS: [BX] 

MOV CX,#+00008H 

PUSH DS 

POP ES 

CLD 

POP DS 

REP M0VSB - cs should have been loaded into ds but wasn;t 

POP DS 

Nothing left on the stack from this routine 



} 



V 



This problem also occurs without the increment. Any constant assignment 
to a dereferenced pointer that generates a M0VSB instruction will cause 
the problem (i.e. pointers to long, double, strings) . This problem is 
caused only when the constants are being stored in the code segment 
(C0NST_prog). 

Temporary solution: 

Modify the assembly file, generated with the $ASM_FILE 0N$ 

directive, to include the required PUSH CS and assemble. 

Signed off 01/14/88 in release Z03.70 



Number: D200074237 Product: 8086/8 C 



64818 



03.02 



One-line description: 

PROGRAMS WITH DUPLICATE GOTO LABELS MAY FAIL IN PASS 3 

Problem: 

C programs with duplicate user labelsffor goto's)may fail in pass3. 

The current SUDS C compilers may produce the error 
"comp: failed; too many errors in pass 3." 
from some C programs which previously compiled correctly. 

This problem did not appear in any C compilers before April 1987. 

In C it is valid to use the same goto label symbol in different 
functions, since they have a logical different scope. 

However, the HP64000 C cross will inform the user that these symbols 
are duplicate in the pass3 on the compiler. These symbols would 
produce duplicate label definitions when defined the ASM_FILE output 
is assembled. In addition the emulation products will only find one 
of these symbols. 



- -0 
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The duplicate symbol detection algorithm on the HPUX/300, HPUX/500 
and VAX/VMS C language compilers has an error which causes the 
compiler to fail. 

However, the duplicate symbol checking is done after all of the 
relocatable and asmb_sym files have been produced. These output 
files are equivalent to those produced in the HP64000 version compilers. 
Thus, the output of the compilers is still correct, except for some 
trailing lines in the listing file. 

The following program will cause this defect to occur: 

"C" 

"6800" 

/* TEST file for problem with duplicate local labels */ 



/* 



V 



/* This program fails in pass 3 on VAX & HPUX/500 &/300 */ 
/* While checking for duplicate asmb_sym symbols */ 
/* due to the "duplicate" error_exit labels */ 



I* 



V 



/* The workaround */ 

/* is to use the same local symbol only once per module */ 

int i; 

testlO 

{ 

/* ... */ 
if (i == 77) goto error_exit; 

/*...*/ 
error_exit: 

i - -i; 
/* ... */ 
} 
/* duplicate symbol should be created */ 

test2l) 
{ 

/* ... V 
if (i « 137) goto error_exit; 

/*...*/ 
error_exit: 

i = -1; 
/* ... */ 



Signed off 01/14/88 in release Z03.70 



SRB detail reports as of 09/01/88 
Number: D200077396 Product: 8086/8 C 
Keywords: CODE GENERATOR 
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03.02 



One-line description: 

VAX and 64100 generate different constants. VAX is incorrect. 

Problem: 

There is a problem with the double constant divide: 

"C" 

"8088" 

main( ) 

{ 

double x; 

X=3. 1415926535898/180.0; 

> 

The program generates an incorrect constant on the VAX, the 64K 
code is fine. 

Temporary solution: 

There is no known solution at this time. 

Signed off 01/14/88 in release Z03.70 

Number: D200077727 Product: 8086/8 C 64818 

Keywords: CODE GENERATOR 

One-line description: 

CL register being used twice 

Problem: 

Compiler uses CX register for two different values 

example: 

"C 
"8088" 



03.02 



#define ushort 
#define uint 



unsigned short 
unsigned 



$FIXED_PARAMETERS 0N$ 
$P0INTER_SIZE=32$ 
$SEPARATE_CONST 0FF$ 
$FAR_LIBRARIES ON$ 
$FAR_PROC 0N$ 
$FAR_EXTVARS$ 

uint arrl[3] [2],arr2[40] ; 
ushort i; 



$LIST_CODE 0N$ 

arr2[20] = arrlfi] [0]/100+30 ; 
MOV CX,#+00064H 



--load CL w/ 100 decimal 



SRB detail reports as of 09/01/88 



Page: 81 



-dividing by 2 not 64H 



MOV BL,DS:BYTE PTR Dstatic+0005CH 

MOV BH,#0 

NOV CL,#+00002H <— CL loaded w/ 2H before 

SHL BX.CL it can be used for divide 

MOV AX,DS:W0RD PTR Dstatic[BX] 

SUB DX,DX 

DIV CX 

ADD AX,#+0001EH 

MOV DS:W0RD PTR Dstatic+00034H, AX 

$LIST_C0DE 0FF$ 

Temporary solution: 

There is no know work around at this time. 

Signed off 01/14/88 in release Z03.70 



Number: D200079111 Product: 8086/8 C 
Keywords: PASS 1 



64818 



03.02 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 

Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SHORT_ARITH OFF$ 

short s; 

unsigned short us; 



ma int ) 



> 



if ((s/usroxffff) 

error! ) : 
if (!us*/.s) A 0x007f ) 

error! ) 
if (us"s) 

error! ) ; 
if (s!=us) 

error! ', 
if (s<us! 

error! ', 
if (s>us) 

error! ' 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



SRB detail reports as of 09/01/88 
Number: D200080051 Product: 8086/8 C 
Keywords: CODE GENERATOR 
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03.02 



Signed off 01/14/88 in release Z03.70 



One-line description: 

Cannot prevent adding Esymbol and Rsymbol info to global symbol table 

Problem: 

When using the linker on the VAX one does not have the capability to 
prevent adding Esymbol and Rsymbol information to the global symbol 
table. This presents a problem for me because I currently have 
approximately 10,000 global symbols in my source code and when I link 
the files this grows to approximately 30,000 symbols because the E and 
R values are added to the linklisting. It becomes very difficult to 
deal with this much information especially since the E and R values are 
of no use to me. I need the capability to turn off the calculation of 
the Entry and Return values for global symbols. 

Temporary solution: 

There is no known solution at this time. 

Signed off 01/14/88 in release 203.70 

Number: D200080333 Product: 8086/8 C 64818 03.02 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 

"C" 

"68000" 

unsigned int a; 

main! ) 

{ 

a=0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 

Signed off 01/14/88 in release Z03.70 



SRB detail reports as of 09/01/88 
Number: 1650038430 Product: 8086/8 C 
Keywords: CODE GENERATOR 
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03.02 



One-line description: 

printer arithmetic gives warning "integer not pointer size" 

Problem: 

Incorrect warning message on instructions using pointers: 

char *p; 

*(p-2)=5; 

gives the message: 

515: Warning: integer not pointer size 

Temporary solution: 

Add, rather than subract from the pointer: 

*(p+(-2)) = 5; 

Signed off 01/14/88 in release Z03.70 



SRB detail reports as of 09/01/88 
Number: 5000221788 Product: 8086/8 C 
Keywords: CODE GENERATOR 
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-0 



One-line description: 

bade code gen if local ptr to extrnl strcture is assgn vlu frm extrn ary 

Problem: 

Bad code generated when local pointer to external structure is 

assigned a value from an external array. Example: 

"C" 

"80186" 

$POINTER_SIZE 32$ 

$FAR_EXTVARS$ 

struct update_msg { char node_id; short neigh_devid[ 16] ; } ; 

extern int tdb[100]; 

main() { int temp_devid; struct update_msg *buffer; 

buffer- >neigh_devid[temp_devid] = tdb[3]; 
} 

The problem is that ES:BX is set up to point to buf fer->neigh_devid[0] , 
then the value tdb[3] is put in AL, which requires that ES be loaded 
with the segment of tdb. Then the value temp_devid is added to BX, and 
finally ES:BX is used to load AL into what should be 
buf fer->neigh_devid[temp_devid] , but is not. 

Temporary solution: 

Break the equation up into smaller pieces. 

create temp variable holdl of integer type. Then do: 
holdl = tdb[3] ; 
buf fer->neigh_devid[temp_devid] - holdl; 

Signed off 01/14/88 in release Z03.70 



- -0 
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Number: 1650004705 Product: 8086/8 PASCAL 

Keywords: CODE GENERATOR 
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02.01 



One-line description: 

Using ES register without initalization - REP MOVSB. 

Problem: 

The following programs demonstrates a code generation problem: 

The ES register is used without initalization. 



BYTE; 

ARRAY [0. .40] OF BYTE; 



END. 

The expanded listing shows that the DS and ES registers are 
pushed, then DS is popped. The following REP MOVSB 
instruction does therefore use the contents of the ES 
register, which was never intialized. 



Signed off 01/14/88 in release Z03.50 
Number: 1650018689 Product: 8086/8 PASCAL 



TYPE 




Pointer 


■ "Record; 


Record 


= RECORD 




first 




last 




END; 


VAR A, B 


: Pointer; 


BEGIN 




A". last 


:- B'.last 



64814 



00.01 



Keywords: CODE GENERATOR 



One-line description: 

Stack POP'S exceed Stack PUSH'S when assignment made to ext var. 

Problem: 

The following program loaded character constants into Const_PR0G 
but fails to load the DS segment with the value of the CS segment 
before a REP MOVSB. This instruction requires the source address to 
be in DS and SI and the destination addres to be in ES and DI. 
WHen CS is not equal to DS the program fails. 

"80186" 

$separate_const 0N$ 
$EXTENSI0NS 0N$ 
$RECURSIVE ON$ 
$FAR_LIBRARIES 0N$ 
$P0INTER_SIZE 32$ 
$FAR_EXTVARS$ 
$GL0BPR0C 0N$ 

PROGRAM TEST; 

TYPE 

- -0 
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CHARSET ' SET OF CHAR; 
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VAR 






SET1 


: CHARSET; 




SEXTVAR 


+ $ 




SET2 


: CHARSET; 




SEXTVAR 


-$ 




BEGIN 






SET1 


:= ['a' , 'b' 


'c'l 


SET 2 


:= ['e',T 


'§'] 



END. 



(* LEA SI,DS:CONST_prog+014H *) 

(* PUSH DS *) 

(* missing PUSH CS here *) 

(* MOV AX.SEG SET2 *) 

(* MOV ES,AX *) 

(* LEA DI,DS:SET2 *) 

(* MOV CX.020H *) 

(* CLD ») 

(* POP DS - this should load CS into DS, but instead it loads *) 

(* DS into DS *) 
(* REP MOVSB *) 
(* POP DS - nothing on the stack from this procedure to pop *] 



Temporary solution: 

No known temporary solution other than identifying the problem 

and editing manually the ASM8086 file, then assembling the ASM8086 

file. 

Signed off 01/14/88 in release Z03.50 

Number: 5000103432 Product: 8086/8 PASCAL 64814 02.01 

One-line description: 

Incorrect code generated in FOR loop. 

Problem: 

8086/8 Pascal compiler generates incorrect code when an mixed 
mode arithmatic is done using array elements indexed by a loop 
variable of type BYTE. 

Temporary solution: 

Use a loop variable of type SIGNED_16. 

Signed off 01/14/88 in release Z03.50 



Number: 5000118844 Product: 8086/8 PASCAL 64814 

Keywords: CODE GENERATOR 

One-line description: 

Wrong code generated for expression in 'FOR' loop 

Problem: 

The following program creates bad code: 



02.00 
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"8086" 

$EXTENSIONS$ 

TYPE 

INT = SIGNED_16: 
STRUC = RECORD 
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SIGNED_16; 
SIGNED_16; 



ARRAY [1..12] OF STRUC; 
ARRAY [1..14] OF SIGNED_16; 
INT; 



END; 
VAR 

$GLOBVAR$ 
TABLE_CADRAGE 
TAB_PAR_SELEC 
PT_TAB_PAR_SELECT 
SGLOBVAR OFF$ 
$GLOBPROC$ 
PROCEDURE CADRER; 
VAR 

VAL : SIGNED_16; 
BEGIN 

FOR PT_TAB_PAR_SELEC := 1 TO 12 DO BEGIN 
VAL := VAL * TABLE CADRAGE[PT TAB_PAR SELECl.A; 
END; 
END; 



compiler puts the limit of the FOR loop in CX 

then moves CX into DX 

then moves DX into BX 

but BX has the pointer of the array stored in it. 



Signed off 01/14/88 in release Z03.50 



Number: 5000124313 Product: 8086/8 PASCAL 



64814 



02.01 



One-line description: 

The library routine, DISPOSE, overwrites the ES register 

Problem: 

The library routine, DISPOSE, overwrites the ES register with out 

restoring it. For example: 

"8086" 

$POINTER_SIZE 32$ 
$FAR_LIBRARIES$ 
$FAR PROC 0N$ 



TYPE 



A = ARRAY [1.. 6] OF BYTE; 
REC : "A; 



VAR P : REC; 

PROCEDURE TEST: 
BEGIN 

NEW ( P ) ; 

DISPOSE(P); 
END; 



SRB detail reports as of 09/01/88 Page: 

This problem was also reported on the 6809 (sr# 5000-124065). 

Temporary solution: 

No known temporary solution. 

Signed off 01/14/88 in release Z03.50 



Number: 5000134817 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



02.01 



One-line description: 

Incorrect address calculated for beginning of ary in WITH stamnt 

Problem: 

The following program generates incorrect code: 
"processor name" 
SEXTENSIONS 0N$ 
PROGRAM TEST; 

TYPE NUM_REC =REC0RD NUM_BUF : ARRAY [1..24] OF BYTE; 
T0T_NUM : BYTE; END; 
PTR = "INTEGER; 
VAR KEY: BYTE; NUM_INP : NUM_REC; POINTER: PTR; 

PROCEDURE DISPLAY (ROW, COLUMN .LENGTH : BYTE; START:PTR;); EXTERNAL; 

PROCEDURE IN; 
BEGIN 

WITH NUM_INP DO BEGIN 
NUM_BUF[TOT_NUM] := KEY; 



ADD 
POINTER: 

MOV 
DISPLAY 
MOV 



BX,AX {BX WILL HOLD ADDR OF TOT_NUM} 

ADDR(NUM_BUF) ; 

DS:W0RD PTR DTEST+01AH.BX {Assumes BX contains addr of 

NUM_BUF, IT DOESN'T} 
5 ,25-T0T_NUM,T0T_NUM, POINTER) ; 

AL,DS:BYTE PTR [BX+00018H] {also assumes this, wrong!} 



END; 
END; . 

Temporary solution: 

Do not use the WITH statement. Reference all record members directly. 

Signed off 01/14/88 in release Z03.50 



Number: 5000138388 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 
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One-line description: 

Incorrect code gener. when shift function operand is mult, dimen. array 
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Problem: 

The following code genrates an "1102 - register needed but not 

available" error: 

"8086" 

PROGRAM TEST; 

SEXTENSIONS 0N$ 

VAR TABLE : ARRAY [0.. 3,0.. 15] OF SIGNED_8; 

BEGIN 

TABLE[2,3] :- SHIFT (TABLE [2, 3] ,4) ; 
END. 

Part of the genrated code looks like: 

MOV CL, #+00004H ;Loads 4 into the counter 
PUSH CX ;Puts 16-bit reg. onto stack 

MOV CH, DS:BYTE PTR DTEST+000023H ;Loads high byte with 

TABLE [2 ,3] 
POP CX ;Takes 16-bit reg. off stack, 

overrides the address of 
TABLE [2, 3] in CH. 
SHL CH.CL ;CH not valid. 

If AL had been used instead of CH, the problem would not occur. 

Temporary solution: 

Use of a dummy variable in the shift function instead of the array 

element will generate the correct code. 

For example: 

"8086" 

PROGRAM TEST; 

SEXTENSIONS ON $ 

VAR TABLE : ARRAY [0 . . 3, . . 15] OF SIGNED_8; 

X : SIGNED_8; 
BEGIN 

X := TABLE[2,3]; 

TABLE[2,3] := SHIFT(X,4); 
END. 

Signed off 01/14/88 in release Z03.50 



Number: 5000163824 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.01 



One-line description: 

Multiplication result stored in CX and overwritten when counter reg need 

Problem: 

Incorrect code generated when 80186 Pascal compiler sees this code: 

"80186" 

SEXTENSIONS 0N$ 
PROGRAM TRY; 

CONST COUNT = UNSINGED_8 (4) ; 
VAR 
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V : ARRAY[UNSIGNED_8(0) .. (C0UNT-UNSIGNED_8( 1) ) ] OF UNSIGNED_16; 

I,X : UNSIGNED_8; 
BEGIN 

X := UNSIGNED_8(2); 

FOR I := UNSIGNED_8(0) TO (C0UNT-UNSIGNED_8 ( 1) ) DO 

V[I] := UNSIGNED_16( (UNSIGNED_8 (4) )*X) ; <« Incorrect code 

END. generated here! 

See verifier text for details. 

Signed off 01/14/88 in release Z03.50 



Number: 5000171876 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 
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One-line description: 

Code produces an #1102 error - reg. needed but not available 

Problem: 

The following code produces compile time error #1102 "register needed 
bu not available" for the 80186 Pascal Cross Compiler (compiler rev 
#3.01 and Op Sys rev #2.04). 



"80186" 

SEXTENSIONS 0N$ 

PROGRAM MISC; 

TYPE 

U_8=UNSIGNED_8; 

U_16=UNSIGNED_16; 

REC1-REC0RD 

A:U_16; 

B:U_8; 

END; 



— > continued from right column 

VAR 

Rl: ARRAY [U_8 (0 ). .U_8(l)] OF REC1; 

X : U_8 ; 

PROCEDURE TEST (N:U_8); 

BEGIN 

X:=R1[R1[N] .A] .A 

END; 



— > continued in left column 

Signed off 01/14/88 in release Z03.50 



Number: 5000171884 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.01 



One-line description: 

BX register gets overwritten when accessing arrays of records 

Problem: 

The following program overwrites the value originally stored in BX 
and then attempts to use BX for the original value. 
See submitter/verifier text for declarations. 

FUNCTION TEST: BOOLEAN; 

BEGIN 

TEST := (U_16(5)*R1[N2[N1]].B) > (U_16(2) *R2[N1].B); 

MUL CL' 
MOV BX.AX 

- -0 
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MOV AX,#00002H 

MOV BX.DX *BX register gets overwritten here 

*which did contain 3*N1 
MUL DS:WORD PTR DMISC[BX+000AH] *WRONG value now in BX 



END; 



Temporary solution: 

Using the compiler option $AMNESIA 0N$ will force the compiler 
to correct this situation. 

OR 
The ASM8086 file can be edited (generated by using $ASM_FILE on$) 
and the line MOV BX,DX can be changed to MOV CX.DX. Also, the line 
CMP BX.AX should be changed to CMP CX,AX. 

Signed off 01/14/88 in release Z03.50 



Number: 5000171900 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.01 



One-line description: 

Contents of register A gets overwritten when accessing mult, arrys of rd 

Signed off 01/14/88 in release Z03.50 

Number: 5000197624 Product: 8086/8 PASCAL 64814 03.01 

Keywords: PASCAL 

One-line description: 

for loop w/ counter = unsignd_8 type uses BX twice 

Signed off 01/14/88 in release Z03.50 



Number: 5000207845 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 
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One-line description: 

bad code for accessing parameters in nested procedures 

Problem: 

Compiler produces bad code when accessing parameters in nested 

procedures. Register are used twice and address are lost. 

Temporary solution: 

There is no known bug at this time. 

Signed off 01/14/88 in release Z03.50 



-0 
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One-line description: 

Using WITH statement and complex record structure causes bad code 

Problem: 

The 8086/8 PASCAL compiler generates code that does not execute 

correctly as documented below: 

FILE TEST5:W0RK 

"80186" 

$extensions on$ 
program tests; 

type 

rectype = record 

vail : unsigned_32; 

val2 : unsigned_16; 

val3 : unsigned_l6; 

pad2 : array [0 .. 255] of unsigned_8; 
end; 

var 

reel : array [unsigned_8( 1 ). .unsigned_8(4) ] of rectype; 

$list_code on$ 

procedure test (aaa,bbb:unsigned_8) ; 

begin 

with recl[aaa] do 
begin 

vail := vail + reel [bbb] .vail; 
val2 := val2 + reel [bbb] .val2; 

mov dx,ds:word ptr [bx+00004h] GETS [AAA] .VAL2 

mov ax,#+00108h 

mul CX --- STOMPS ON [AAA] .VAL2 

mov si, ax 

add dx,ds:word ptr dtest5[si-00104h] — ATTEMPTS TO 

ADD [BBB].VAL2 TO GARBAGE 
mov ds:word ptr [bx+00004h] ,dx 
val3 := val3 + reel [bbb] .val3; 

mov dx,ds:word ptr [bx+00006h] SAME PROB. AS ABOVE 

mov ax,#+00108h 
mul ex 
mov si, ax 

add dx,ds:word ptr dtest5[si-00102h] 
mov ds:word ptr [bx+00006h] ,dx 
end; 
end. 



Temporary solution: 

The bugs will disappear if either $amnesia$ is turned on or if the 

first operation is not a 32-bit operation. 

- -0 
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Number: D2000 19273 Product: 8086/8 PASCAL 64814 01.10 

Keywords: RUN-TIME LIBRARY 

One-line description: 

Problem with Pascal 1/0 library (PI0LIB). 

Problem: 

When using the Pascal 1/0 library (PIOLIB), run-time error messages 
are not correctly returned to the 'Abort' routine. The routine 'Perror' 
places the error message into the DATA segment (DS) while 'Abort' 
assumes the message is in the CODE segment. 

Please call your Hewlett-Packard Sales Representative in the event 
you experience this problem. 

Temporary solution: 

No known workaround at this time. 

Signed off 01/14/88 in release Z03.50 



Number: D200022137 Product: 8086/8 PASCAL 
Keywords: RUN-TIME LIBRARY 



64814 



01.10 



One-line description: 

Real number comparisons may not 'evaluate' correctly. 

Problem: 

Real number comparisons, i.e. >, <, > = , <■=, = , may not be evaluated 
correctly with numbers having six (6) or more significant places. For 
example, the following IF statement will NOT be evaluated correctly. 

a := 12.3456; 
b := 12.3455; 
IF a > b THEN 

result :« 1 
ELSE 

result :- 0; 

In the above example, 'result' will equal '0'. 

Temporary solution: 

No known workaround at this time. 

Signed off 01/14/88 in release Z03.50 



Number: D200023283 Product: 8086/8 PASCAL 

Keywords: CODE GENERATOR 

One-line description: 

Illegal PUSH instruction generated. 

- -0 



64814 



01.10 
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Problem: 

Compiling the following program will cause the compiler to generate 
an incorrect PUSH statement. 

$POINTER_SIZE 32$ 
PROGRAM TEST; 
$EXTENSI0NS$ 

VAR 

VARIABLE : INTEGER; 

PROCEDURE PROC_0NE (OFFSET : UNSIGNED_16) ; EXTERNAL; 

BEGIN 

PR0C_ONE (UNSIGNED_16(ADDR(VARIABLE) ) ) ; 
END. 

The PROC^ONE ( . . . ) statement will cause the compiler to generate a 
PUSH BL Instruction which is illegal. 

Temporary solution: 

This problem appears to be related to the use of 32 bit pointers 
in conjunction with the ADDR function. 

Signed off 01/14/88 in release Z03.50 



Number: D200053710 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.00 



One-line description: 

Var. addresses incorrect inside nested WITH statements 

Problem: 

THE F0LLW0ING CODE WAS TAKEN FROM THE PROGRAM LISTED IN THE SUBMITTER 
TEXT. tHE FIRST LINE GENERATES A DIFFERENT VALUE FOR HIGH_BYTE THAN 
THE SECOND TWO LINES. 

DATA_BYTE [SOURCE_MOST_SIGN] := CRCS_10_ADDR [CRCS_10_NUM] .HIGH_BYTE; 

WITH CRCS 10_ADDR [CRCS_10 NUM] DO 
DATA_BYTETSOURCE_MOST_SIGNT :- HIGH_BYTE 

Another example of this problem can be found on Ihplsdsb under 
users/rob in/awabug.s 

Temporary solution: 

Do not use nested WITH statements. 

Signed off 01/14/88 in release Z03.50 



-0 
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Number: D200063750 Product: 8086/8 PASCAL 
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03.01 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 

"processor" 

PROGRAM BAD_DATA; 



EVENT ■ 


» RECORD 


A 


BYTE; 


B 


BYTE; 


C 


INTEGER; 


D 


BYTE; 


END; 





VAR EVENT 1 



EVENT ; 



PROCEDURE 
BEGIN 

EVENT 1 
END; 



GENERATOR! 



EVENT(O); { THIS ASSIGNMENT RESULTS IN BAD DATA } 



BEGIN 
END. 

Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release 203.50 



Number: D200065060 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.01 



One-line description: 

FOR loop counter gets destroyed when loop includes multiple WITH's 

Problem: 

The following program demonstrates the FOR loop counter 
being destroyed. This problem only occurs if the WITH 
contains at least 3 records and the record I0JJNITS has the 
variable VOLT at least third in the variable list. 

The code generated stores the FOR loop counter into CX, then 
it later moves the counter to DI in preparation for the M0VSB 
instruction for which uses CX. However, MOVSB uses DI as well. 
The counter gets lost when the destination for the string move 
is loaded into DI. 

"8086" PREPROCESS 



-0 
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PROGRAM TEST; 
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TYPE 




LOD LIM * 


RECORD 




MIN HEAD : REAL; 




END; 


10 UNITS 


- RECORD 




G MW,G MVAR.VOLT : REAL; 




END; 


GEN LOAD 


= RECORD 




B gener mw : REAL; 




B volt : REAL; 




END; 



$GLOBVAR ON$ 
VAR 

units : SIGNED_16; 

GEN_C0N : ARRAY [1.. 17] OF GEN_L0AD; 

I0_GN : ARRAY [1..17] OF I0_UNITS; 

LL_GN : ARRAY [1..17] OF L0D_LIM; 
SGL0BVAR 0FF$ 

PROCEDURE BUFFER_DATA; 
BEGIN 

FOR units := 1 TO 17 DO 

{MOV CX,#+11H - loads ex with 17} 
BEGIN 
WITH GEN_C0N [units] ,LL_GN[units] , 

{MOV AX.CX - counter now in ax} 
IO_GN[units] DO 

{MOV CX,AX - counter moved back into CX} 
BEGIN 

B_volt := VOLT; 

{MOV DI.CX - moves counter into DI} 
{MOV CX, #4H - destroys contents of ex} 
B_gener_mw := G_MW; 

{LEA DI .memory loc - destroys counter in DI} 
END {WITH}; 
END {FOR}; 

{MOV CX,DI -loads counter back into ex, but counter) 
{ isn't in DI} 
{LOOP - decrements counter} 
END {BUFFER_DATA}; 

BEGIN 

BUFFER_DATA; 
END. 



Temporary solution: 

The temporary solution requires that an IF statement be added 

to the BUFFERDATA procedure. 



Change: WITH GEN_CON[units] ,LL_GN[units] 
IO_GN[units] DO 
BEGIN 

- -0 
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B_volt := VOLT; 

To: WITH GEN_C0N [units] ,LL_GN [units] , 
I0_GNlunits] DO 
BEGIN 

IF (1=1) THEN x := TRUE; 

{x roust tie declared as a boolean variable} 

B_volt := VOLT; 

Signed off 01/14/88 in release Z03.50 . 

Number: D200068759 Product: 8086/8 PASCAL 64814 03.02 

One-line description: 

WITH construct causes wrong offset 

Problem: 

The examples for this problem have been given to the lab (file 

Problem3) 

When using the WITH construct, the compiler calculates the correct 
offset for the variable in the FOR statement, but it fails to save 
the segment part of the pointer. Later it loads in a random number 
as this segment address. This only occurs when the IF statement is 



Addr_max] OF CHAR; 



SRB detail reports as of 09/01/88 

Event_type = UNSIGNED_16; 
Addr_type = RECORD 

Len : BYTE; 
Adrtype : BYTE; 
Digits : ARRAY [Addr_min 
END; 

User_cat = ( No_bar, Bar_l, Bar_2); 
e_Analys_b_no = RECORD 

Dest_addr_type; 
Cat : User_cat; 
END ; 
Ana_res_type = (Next_digit,Local_call,No_ j _convert , 

Outgoing_call, Invalid_dTgit ) ; 
Signal = RECORD 

Link, Backlink : Signal_p; 
Que : que_type ; 
Duration : Timer_type; 
Address, Sender : Pid; 
CASE Event : Event type OF 

Analys_b_no : TAnalys_b_no_e : e_Analys_b_no) 
END; 
Analysis_Result = RECORD 

Result : Ana_res_type; 
CASE Ana_res type OF 
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inside the WITH statement. 


Next digit : (Ana index, dummyl : BYTE); 




Local_call : (Mult_no :UNSIGNED_16) ; 




No convert : (Conv index, dummy2 : BYTE ); 


••80186" PREPROCESS 


Outgoing call : (Rout index, Bar c:BYTE); 


$EXTENSIONS 0N$ 


Invalid digit : (dummy3 : INTEGER); 


$RECURSIVE ON$ 


END; 


$P0INTER SIZE 32$ 


No_sub_table = ARRAY [0..15] OF Analysis_result; 


$FAR LIBRARIES 0N$ 


Table_p - "No_sub_table; 


$FAR PROC 0N$ 


Conv type = (Replace no, Delete digits, Add_digits,Del_and_add) ; 


$SEPARATE_CONST 0FF$ 


Conv_elements = RECORD 




Conversion : Conv type; 


PROGRAM CC_ANALYSIS_job; 


Del position : BYTE; 




Number of del : BYTE; 


CONST 


Add position : BYTE; 


MAXINT = 32767; 


Number of add : BYTE; 


Addr_min = 


Newe digits : ARRAY [1..15] OF CHAR; 


Addr max - 8; 


END; 


Analys b no = UNSIGNED16( 196) ; 




Analys_res = UNSIGNED _16(197); 


VAR 




sig : Signal p; 


TYPE 


i : BYTE; 


INTEGER = SIGNED 16; 


Analys li : BYTE; 


Time type = UNSIGNED 16; 


Analys_no : ARRAY [1..15] OF BYTE; 


#DEFINE 0RD INTEGER; 






SRECURSIVE 0FF$ 


TYPE 




que type « ( timer que, event que); 


FUNCTION IAS converted : BOOLEAN; 


Ptr •= "INTEGER; 


VAR 


Pid = RECORD 


i : BYTE; 


dma : BYTE; 




process : INTEGER; 


BEGIN 


END; 


IA5 convertede : = TRUE; 


Signal_p = "Signal; 


WITH sig",Analys_b_no_e,Dest_adr DO 


- -0 


- -0 



SRB detail reports as of 09/01/88 

IF Len ■= 

MOV DS:WORD PTR DIA5_converted+00006H,SI 
{but does not save segment} 

THEN IA5_converted :» FALSE; 
ELSE FOR i := 1 TO Len DO 
CASE Digits[i] OF 

LES BX,DS:W0RD PTR DIA5_converted+0006H 

{this loads garbage into ES} 
'0' ,'1' ,'2' ,'V ,'4' ,•$' 
Analys_no[i] 
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6', '7', '8', '9' 

:= BYTE(Digits[i] 



'*' : Analys no[i] 


= 10 




'#' : Analys no[i] 


= 11 




'A' : Analys no[i] 


- 12 




'B' : Analys nofi] 


= 13 




' C : Analys nofi] 


= 14 




'D' : Analys nofi] 


= 15 




END; 


Analys li := sig^. Analys b no e.Dest adr.Len 


END; 


BEGIN 


END. 


END; 


END; 


BEGIN 


END. 







'0'); 



Temporary solution: 

No known temporary solution. 

Signed off 01/14/88 in release Z03.50 

Number: D200068767 Product: 8086/8 PASCAL 64814 03.02 

One-line description: 

With construct causes wrong offset 

Problem: 

The examples for this problem have been given to the lab (file 

Problem4) 

An globally ORGed variable is accessed inside a Procedure using 
a WITH construct. The array offset is calculated and stored in 
the AX register. It is then moved to the BX register. When the 
offset is changed, the code access the AL register instead of the BX 
register. Hence, the wrong offset into the array is calculated. 

This problem does not occur when the variable is load to the 
procedure. 

•'80186" PREPROCESS 
$EXTENSIONS 0N$ 
{RECURSIVE 0N$ 



SRB detail reports as of OS/01/88 

$P0INTER_SIZE 32$ 
$FAR_LIBRARIES 0N$ 
$FAR_PR0C 0N$ 
$SEPARATE_CONST 0FF$ 

PROGRAM WITHTEST; 

CONST 

MAXINT = 32767; 

TYPE 

INTEGER = SIGNED_16; 
#DEFINE 0RD INTEGER; 

TYPE 

Tilst_txt lintyp = RECORD 

Pos_L : BYTE; 

Pos_H : BYTE; 

Li " BYTE" 

Txtstring': ARRAY [1..42] OF BYTE; 

END; 
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p; 



Tilst_txt_element = RECORD 

Tilst_txt lin : ARRAY [1..2] OF Tilst_txt_linty 

END; 

Tilst_txt_type = ARRAY [0..16] OF Tilst_txt_element ; 



VAR 



$0RG 20000000H$ 

X :BYTE; 
$END_0RG$ 

$EXTVAR 0N$ 

Tilst_txt : Tilst_txt_type; 

SEXTVAR 0FF$ 

PROCEDURE FAST_TXT_TILST(Tilst_txtnr,Linie_ofset : INTEGER); 

VAR 

N : INTEGER; 

{ X : BYTE; makes the problem go away } 
BEGIN 

WITH Tilst_txt[Tilst_txtnr] DO 
BEGIN 

FOR N := 1 TO 2 DO 
BEGIN 

X := Tilst_txt _lin[N] .Pos _1; 

SUBAL,#+002DH (shold be SUB BX,#+002DH) 



END; 



END; 



-0 
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END; 

BEGIN 
END. 

Temporary solution: 

No known temporary solution. 

Signed off 01/14/88 in release Z03.50 
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Number: D200075952 Product: 8086/8 PASCAL 



64814 



03.02 



One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

SEXTENSIONS 0N$ 
PROGRAM DOLOOP; 



VAR 



SECTORNUM, STOPSECTOR 
A 



UNSIGNED 
INTEGER;" 



BEGIN 

STOPSECT0R : = UNSIGNED_8(247) ; 

FOR SECTORNUM := UNSIGNED_8 (0 ) TO STOPSECTOR DO BEGIN 

A := 5; 

END; 

END. 

Temporary solution: 

USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 

'PROCESSOR" 
SEXTENSIONS 0N$ 
PROGRAM DOLOOP; 



VAR 



SECTORNUM , STOPSECTOR 

A 



UNSIGNED_16; 
INTEGER; 



SRB detail reports as of 09/01/88 
BEGIN 

STOPSECTOR := UNSIGNED_16 (247 ) ; 

FOR SECTORNUM := UNSIGNED 16(0) TO STOPSECTOR DO BEGIN 
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END. 



A := 5; 
END; 



This works for values up to 8000H. 
Signed off 01/14/88 in release Z03.50 



Number: D200077875 Product: 8086/8 PASCAL 



64814 



03.02 



One-line description: 

$RECURSIVE $ option defaults to incorrect mode (OFF) 

Problem: 
"80188" 

PROGRAM ERROR; 
PROCEDURE ERR_3; 

VAR A,B : SINGED_16; 
BEGIN 
A:- B; 

MOV AX,DS:W0RD PTR DERR_3+0002H 
MOV DS-.WORD PTR DERR_#, AX 
ERR_3; 

CALL FAR PTR ERR_3; 
END; 

The $RECUSRSIVE$ option should default to ON, but instead defaults 
to OFF. 



Temporary solution: 

Use explicit Directive in program. 

Signed off 01/14/88 in release Z03.50 



Number: D200078642 Product: 8086/8 PASCAL 
Keywords: CODE GENERATOR 



64814 



03.00 



One-line description: 

pointers passed as procedure parameters not fully dereferenced. 

Problem: 

When passing a pointer to a pointer to a record, the pointer is not 

fully dereferenced. See verifier text for example. 

SEXTENSIONS 0N$ 
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SF.B detail reports as of 09/01/88 

$SEPERATE_CONST 0FF$ 
$GEPARATE ON$ 
$FAR_PR0C 0N$ 
SGLOBPROC ON$ 
$FAR_LIBRARIES $ 
$POINTER_SIZE 32$ 
SFAR_EXTVARS$ 
^RECURSIVE ON$ 
SOPTOMIZE ON$ 
f.DEBUG 0FF$ 
SIOCHECK OFF$ 
$FULL_LIST OFF$ 
$LIST_CODE OFF$ 
$LIST_OBJ OFF$ 

PROGRAM Error_15; 

TYPE 

ARTIKEL = RECORD 

ELE1 : SIGNED_16; 
ELE2 : SIGNED_16; 
END; 
ARTIKEL_PTR = "ARTIKEL; 

PROCEDURE ART_DEFAULTS(VAR ART : ARTIKEL); 

BEGIN 

END; 

{this is the problem routine} 

PROCEDURE ERR_15(VAR ART : ARTIKEL_PTR) ; 

BEGIN 

ART_DEFAULTS( ART") ; {< this generates the following error code) 

PUSH SS: [BP+00O0AH] 

PUSH SS: [BP+00008H] 

CALL FAR PTR ART_DEFAULTS 
{The variable art" was never fully dereferenced. It now points at 
a pointer to ARTIKEL, not at ARTIKEL} 

END; 



Temporary solution: 

PROCEDURE W0RK_15(VAR ART : ARTIKEL_PTR) ; 

VAR 

A : ARTIKEL_PTR; {this solution will fully dereferene the pointer} 
BEGIN 

- -0 
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A := ART; 
ART_DEFAULTS(A") ; 
END; 

Signed off 01/14/88 in release Z03.50 
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Number: D200079194 Product: 8086/8 PASCAL 



64814 



03. o: 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 

changes physical size), when it should generate a fatal error. It 

tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 

"PASCAL" PREPROCESS 
"6809" 

{ Test program to demonstrate Pascal language defect } 
{ Functional type change of constant to multi-byte variable } 
PROGRAM PTEST101; 
$EXTENSIONS 0N$ 
TYPE event = RECORD 

type : BYTE; 
qualifier: BYTE; 
msg : INTEGER; 
send_task: BYTE; 
END; 
VAR event 1: event; 
i: INTEGER; 
R: REAL; 

BEGIN 

{The following code is attempting to initialize} 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 



eventl := event(O) 



{This code is incorrect Pascal) 



SRB detail reports as of 09/01/88 



{Correct Pascal using individual assignments) 

eventl. type: =0 ; 

event 1. qualifier: =0 ; 

eventl. msg: =0 ; 

eventl. send_task: =0 ; 
END. 



Jigned off 01/14/88 in release Z03.50 
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Number: D200079251 Product: 8086/8 PASCAL 
Keywords: PASS 1 



64814 



03.02 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 



SEXTENSIONS 0N$ 
PROGRAM PTEST; 



VAR 

S8 
U8 
S16 
U16 

BEGIN 
U16 
U16 



SIGNED_8 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 



= UNSIGNED_16(S8) 
:= UNSIGNED 8(S8) ; 



END. 



S16 := SIGNED_16(U8) ; 
S16 := SIGNED 8(U8l ; 



(* signed extension of S8 - correct *) 
(* signed extension of S8 - incorrect *) 

(* unsigned extension of U8 - correct *) 
(* unsigned extention of U8 - incorrect *) 



Signed off 01/14/88 in release Z03.50 
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Number: 5000121830 Product: 9900/0 ASSEMB 

Keywords: CODE GENERATOR 



64847 



Page: 106 

00.46 



One-line description: 

Autoincrement with indirect addressing does not assemble correctly. 

Problem: 

THE HOSTED 9989 ASSEMBLER/LINKER ON THE 9000 DOES NOT ASSEMBLE 

CORRECTLY WHEN THE CUSTOMER USES THE INDIRECT ADDRESSING WITH 

AUTOINCREMENT. THE CODE DOES ASSEMBLE CORRECTLY ON THE 64000. 

EXAMPLE: 

MOV R11,*R7+ 
AND 

INC *R6+ 

GENERATES THE ERROR MISSING OPERATOR, AN ARITHMETIC OPERATOR WAS 
EXPECTED AND WAS NOT FOUND ON THE HOSTED SOFTWARE. 

Temporary solution: 

There is no know work around at this time. 

Signed off 01/14/88 in release Z01.80 



Number: 5000232959 Product: 9900/0 ASSEMB 
Keywords: CODE GENERATOR 



64847 



00.00 



One-line description: 

Problem with negative displacementwith SBO SBZ instructions. 

Temporary solution: 

All constants have a 32 bit internal representation. When negative 

numbers need to be reprsented, the following syntax should be used: 

SBO 0FFFFFFFFFH 

When the used does not put 8 F's, the system sign extends the high 
order bytes, and interprets the number as positive 255, outside the 
legal range for this instruction. 

Signed off 01/14/88 in release Z01.80 

Number: D200035220 Product: 9900/0 ASSEMB 64847 00.46 

One-line description: 

In macros, "" and '' are not equivalent. 

Problem: 

In macros, "" and ' ' are not equivalent, but should be as defined in 

the manual. 

Signed off 01/14/88 in release Z01.80 
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Number: D200093369 Product: 9900/0 ASSEMB 

Keywords: PROBLEM ON VAX 



64847 
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One-line description: 

•PRODUCT # CHANGE on the VAX* From= 64xxxS003 To=64xxxM003 

Problem: 

This Service Request has been entered to inform users of the product 

THAT: 

The *PR0DUCT NUMBER has CHANGED on the VAX version of this product 

FROM (OLD Product Number)- 64xxxS003 < The real change being 

< the "S" changed to "M" 
TO (NEW Product Number) = 64xxxM003 < in this Product Series 

(The "xxx" in the above to be filled in with the Product Number 
against which this SR is entered... This text applies to many 
SR's and is generic in nature.) 

The above event happend without a change to the REVISION CODES on the 
PRODUCT. 

This event happend on the revision code that was used to sign off 
this Service Request. 

Signed off 08/23/88 in release A01.80 
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Number: 5000224022 Product: F9450 EMULATION 



64286 
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One-line description: 
Answer to "Emulate SCR?" 



is automatically changed to "yes" 



- -9 



Problem: 

If the emulator is configured for 17 bits of address or greater, 
and the user modifies the memory configuration, then the 
configuration setting of "emulate the system configuration 
register" is set to "yes" even if the user had previously set 
the response to "no" . 

Temporary solution: 

If you don't want to emulate the SCR, and you are using 17 bits 
of address or greater, then you must always check the answer to 
"emulate system configuration register?" to be sure that the 
answer is "no" . 

Signed off 01/14/88 in release Z01.05 

Number: 5000164004 Product: F9450 EMULATION 64286 

Keywords: ENHANCEMENT 

One-line description: 

Cannot single step through a Software Breakpoint 

Problem: 

It is not possible to single step through a Software Breakpoint 
and have the breakpoint actually function properly. If you 
step the BEX code, you end up single stepping the monitor 
code itself at the Software Break Entry location. Since the 
monitor is not re-entrant, this causes some minor problems. 
The biggest problem is that the user's registers and IC get 
lost since the monitor itself uses some of the registers. 

This problem occurs most often when the user has multiple 
software breakpoints set. The user encounters a software 
breakpoint while running, then decides to single step the 
code at the breakpoint location. The user then accidentally 
single steps the BEX code itself and finds himself stepping 
the emulation monitor code. 

Temporary solution: 

A good work-around for this problem is to "modify software 
breakpoints clear" after breaking to the emulation monitor. 
Then perform the single stepping that is desired. And to 
restore all of the breakpoints, just enter "modify 
software_breakpoints set" before using the "run" command. 

Signed off 01/14/88 in release Z01.05 



01.03 
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Number: D200066357 Product: F9450 EMULATION 

Keywords: ENHANCEMENT 
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One-line description: 

MASK, STATUS, and IC are not always cleared when running from reset. 

Problem: 

When you enter the monitor from a hardware reset, the MASK, 
STATUS word, and Instruction Counter contain the values that 
existed at the previous break entry into the monitor. These 
three registers should be cleared when running in the monitor 
from a reset condition since the F9450 cpu will clear the 
same registers after a reset. Note that the values are 
initialized to zero in the assembly code for the monitor, but 
there is no code that actively resets the values to zero upon 
entering the monitor at the RESET_IN location. 

Signed off 01/14/88 in release Z01.05 



Number: D200068957 Product: F9450 EMULATION 
Keywords: ENHANCEMENT 



64286 



01.04 



One-line description: 

Enhance the register display to show the Pending Interrupt Register 

Problem: 

The current register display does not show the Pending Interrupt 

Register. 

Temporary solution: 

A good temporary implementation of this enhancement can be made 
by the user of the F9450 emulator. The emulation monitor can 
be modified such that the PIR is displayed in place of the 
Fault Register. All that is necessary is a small modification 
to the F9450 monitor program so that the PIR is stored in the 
memory location where the Fault Register is now stored. 

To implement this idea, replace the instruction XIO R14,RCFR 
with the instruction XIO R14,RPIR in the "UNLOAD" section 
of the monitor, M0N_9450 : HP: source. 

Signed off 01/14/88 in release Z01.05 
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Number: 1650019257 Product: HOST SOFTWARE / VAX 64882 

One-line description: 

VAX help on MAPBUS command causes system error 
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01.20 



Problem: 

Digital VMS help command gives an access violation when part of a 
keyword is entered and the help file has a blank line after the 
keyword. The MAPBUS help entry has a spurious blank line after the 
MAPBUS keyword. 

Temporary solution: 

Delete spurious blank line after MAPBUS keyword in help file. 

Signed off 01/14/88 in release Z02.30 



Number: D200069104 Product: HOST SOFTWARE / VAX 64882 



01.70 



One-line description: 

64100 cluster disk free list is corrupted so there is not enough space 

Problem: 

The HSL seems to destroy the free page list during operatino. 
Transfer reports no space available to transfer the file. 
Directory reports no space available. Directory of all user ids 
shows that the disk has a significant portion remaining. (+20X) 
This appears to be happenning at 4 sites. One site has sent 
me an image backup made after the problem occurred. This is 
probably just a VAX HSL link problem. 

Temporary solution: 

SOFT FIX will generally repair the problem, or at least indicate any 

exceptionally large files on the disk. These files can then be purged. 



Signed off 01/14/88 in release Z02.30 



Number: D200082669 Product: HOST SOFTWARE / VAX 64882 02.00 

Keywords: TRANSFER 

One-line description: 

CSIB process does not come up on system bootup 

Problem: 

CSIB process does not come up on system boot-up. The following error 

message is seen on the system console: 

CSIBx: unable to connect to HSL driver, check installation. 

This is an intermittent problem, and rebooting the system can work. 

Temporary solution: 

Try rebooting the system until the CSIB process comes up. 

Signed off 01/14/88 in release Z02.30 
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Number: D200082636 Product: HOST SOFTWARE / 300 64883 01.00 

One-line description: 

Transfer does not handle imbedded linefeeds in binary files. 

Protleir.: 

Transfer software not capable of handling imbedded linefeeds in binary 

files. 

Signed off 01/14/88 in release Z01.10 
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Number: 1650018721 Product: HOST SOFTWARE / 500 64880 



Page: 
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01.60 



One-line description: 

Debug file transfers may not function with 14 character file names. 

Problem: 

Debug file transfer may not function correctly when 14 character file 
names are used during program development. As an example, consider 
the following: 

1) create a source file with a 14-character filename 
(i.e., "source7890ab.C" ) and compile 

2) link the relocatable file and create an absolute 
filename of the form "source7890ab.X" ) 

3) transfer the data to a 64000 system using the 
command 

$ transfer -thda source789ab.L :TMP 

Transfer will report problems with one of the temporary files 
which transfer created. 

Signed off 01/14/88 in release Z01.80 

Number: 5000219204 Product: HOST SOFTWARE / 500 64880 01.06 

Keywords: TRANSFER 

One-line description: 

Bad file format does not cause error in transfer. 

Problem: 

The transfer software will successfully transfer files with 
formats that are not supported. For example, an absolute file 
with records greater than 256 bytes will successfully transfer. 
However, this file will cause unpredictable problems on the 
destination system. 

The example given is a file transfered from 500 to 64000. This 
transfer completes successfully. When the file is transfered 
back to the 500, an error is generated and the transfer is not 
complete. The error gives no indication that the file format 
is wrong. 

Temporary solution: 

To insure the successful transfer and usability of files, 
the users should use the utility read64 on files to be 
transfered. This utility will indicate the size of the 
records in the files. For a description of the format of 
absolute files, see manual 64880-90903. 

Signed off 01/14/88 in release Z01.80 



-0 
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Number: D200019265 Product: HOST SOFTWARE / 500 64880 01.10 

One-line description: 

Invalid file names are not detected by the transfer utility. 

Problem: 

When constructing the transfer command as a one line command, the 
transfer software does not verify the syntax of the 64000 file name 
before sending the command to the 64000. The result is a syntax error 
on the 64000 for invalid file names. 

Signed off 01/14/88 in release Z01.80 
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Number: D200093393 Product: MS1750A ASSEMB 

Keywords: PROBLEM ON VAX 



64857 



Page: 114 

00.00 



One-line description: 

*PR0DUCT # CHANGE on the VAX* From- 64xxxS003 To=64xxxM003 

Problem: 

This Service Request has been entered to inform users of the product 

THAT: 

The *PRODUCT NUMBER has CHANGED on the VAX version of this product 

FROM (OLD Product Number)= 64xxxS003 < The real change being 

< the "S" changed to "M" 
TO (NEW Product Number) = 64xxxM003 < in this Product Series 

(The "xxx" in the above to be filled in with the Product Number 
against which this SR is entered... This text applies to many 
SR's and is generic in nature.) 

The above event happend without a change to the REVISION CODES on the 
PRODUCT. 

This event happend on the revision code that was used to sign off 
this Service Request. 

Signed off 08/23/88 in release A01.90 



- -0 



- -S 
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Number: 1650006908 Product: OPERATING SYSTEM 64100 00.01 

Keywords: DC600 

One-line description: 

64000 backup from 7946 to 9144 with 150' tape produces wrong message. 

Problem: 

Backup to a 9144 tape drive and using a tape that is too small 
for the disc, i.e. a 150' tape, will produce an incorrect message: 
"Disc and DC600 units must be at the same controller address" 

Temporary solution: 

Multi-tape backups to a 9144 are not currently supported on the 


SRB detail reports as of 09/01/88 Page: 116 

command file, it first shows a number of retries, than it seems to 
format but at the end 'System area on disc bad: format failed' 
is displayed. 

Formatting by giving the command manually, always goes well. 
Formatting from a command file sometimes goes well but mostly not. 
The floppy used was a 'XIDEX' precision flexible disk. 

Temporary solution: 

A temporary solution is to put something in the command file to delay 
execution of the next command until the drive has finished initial- 
ization. 

Signed off 01/14/88 in release Z02.10 


64000 system. 

Signed off 01/14/88 in release 202.10 


Number: 5000181552 Product: OPERATING SYSTEM 64100 02.04 
Keywords: DC600 


Number: 1650033209 Product: OPERATING SYSTEM 64100 02.07 

One-line description: 

Unique label is flagged as undefined in macro expansion. 


One-line description: 

No multi-tape backup strategy for discs > 64MB on the 64000. 

Signed off 01/14/88 in release Z02.10 


Problem: 

Using labels in macro causes incorrect error message 

Error-ML - Macro Label, Label not found within macro body. 

"68000" 

REGMEMS MACRO MNST,&FPM,&EA,MX 

.IF "MX" .EQ. LLLL1 &&&& 

MOVE.L D0,D1 
LLLL1 &&&& MOVE.L D1,D0 
NUL REL TST.B D7 

MEND 


Number: 5000189985 Product: OPERATING SYSTEM 64100 02.07 

One-line description: 

Instructions assembling differently than previous assembler. 

Problem: 

TWO INSTRUCTIONS ASSEMBLE DIFFERENTLY THAN THEY DID ON A PREVIOUS RELEAS 

E. THIS WOULD REQUIRE CHANGING A GREAT DEAL OF CODE. 

FOR MACROS IF LABLE.EQ.LABLE2 



The errors occur in the maocro calls within the main program: 

*Main Program 

REGMENS FM0VE,FP0,D1 
.IF " .EQ. "" LLLL1JJ001 

ERROR-ML 



Temporary solution: 

No temporary solution known at this time. 

Signed off 01/14/88 in release Z02.10 



Number: 5000111666 Product: OPERATING SYSTEM 



64100 



02.01 



One-line description: 

Formatting a floppy from a command file sometimes is unsuccessful. 

Problem: 

When the 64941 floppydrive is used to initialise a floppy from a 



NOW GIVES ERRORS UNLESS BLANKS ARE ADDED ON EACH SIDE 
OF . 

IF LABLE . EQ . LABLE2 

FOR REFERENCES OF THE TYPE [A1.D3.L] THERE IS NOW AN ERROR POINTING TO 
THE .L WHICH SAYS MISSING OPERAND. 

Temporary solution: 

No temporary solution known at this time. 

Signed off 01/14/88 in release Z02.10 

Number: 5000202770 Product: OPERATING SYSTEM 64100 02.06 

One-line description: 

Logical operators generate MO error. 

Problem: 

All assemblers generate Missing Operand error at logical operator. 

For example the .NE. operator will generate an error. 



-P 
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Temporary solution: 

Reload operating system 2.05. 

Signed off 01/14/88 in release Z02.10 
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Number: D200027953 Product: OPERATING SYSTEM 
Keywords: COPY 



64100 



02.01 



One-line description: 

"copy f:link_com to display" doesn't display all attributes of "f". 

Problem: 

Link a file with list, xref, overlap_check, and comp_db on. Then, when 
one does "copy f ile: link_com to display", only the values for map and 
xref appear. 

Temporary solution: 
None at this time. 

Signed off 01/14/88 in release Z02.10 



Number: D200062604 Product: OPERATING SYSTEM 



64100 



02.04 



One-line description: 

Comment is taken as a parameter when a null parameter is passed. 

Problem: 

If you invoke a macro with a null parameter and a comment 
is included on the line, the comment will be taken as 
the parameter (even with a semi-colon). 



DONE 



"68000" 








X 


MACRO 




&PARM 




.IF 




"&PARM".EQ. 




MOVE 




#3, DO 


DONE 


.NOP 
MEND 








X 


HI 






X 




;THIS 




END 







THIS COMMENT WILL BE A PARAM. 



Temporary solution: 

No work around at this time other than not placing comments 

on the macro invokation line. 

Signed off 01/14/88 in release 202.10 
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Number: D200085050 Product: OPERATING SYSTEM 



64100 



Page: 118 

02.07 



One- line description: 

Phase error incorrectly reported on 64000 and hosted assemblers. 

Problem: 

The 1750 assembler reports a spurious error message PH_ERR (Phase 
error) due to the usage of C0UNTER_UPDATE vs. GEN_C0DE in passes 1 
and 2 of the assembler. 

Cause: 

This defect has been fixed and this report is 
being submitted for QA release purposes. 

Temporary solution: 
None At this Time... 

Signed off 01/14/88 in release A02.10 



-P 
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Number: 5000223792 Product: IMS 32010 MODULES 



Page: 



64285 



119 
01.00 



One-line description: 

Inverse assembly for 1E91H is incorrectly shown as SUB *-, 

Problem: 

The instruction code 1E91H should be inverse assembled to 

"SUB *-, E,l" but instead is displayed as "SUB *-, E,0" 

Temporary solution: 

Until this problem is fixed, you can verify whether the 
inverse assembly is correct by examining the code itself. 
1E91H is the code for SUB *-, E, 0. 

Signed off 01/14/88 in release Z01.02 
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Number: D200081620 Product: USER DEF ASSEHB 500 64851S001 01.60 

One-line description: 

expressions of the form 123456.78 cause errors 

Problem: 

There is a problem with the expression handler on the hosted software 
when parsing expressions of the form 12345.67, which the assembler 
thinks is a real number. This problemis shown in sample code supplied to 
Dave Ritchie by JLO in conjunction with the 64180 assembler. 

Signed off 01/14/88 in release Z02.10 



- -S 
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Number: D200081638 Product: USER DEF ASSEMB VAX 64851S003 01.60 

One-line description: 

expressions of form 123456.78 cause errors 

Problem: 

There is a problem with the expression handler on the hosted software 
when parsing expressions of the form 12345.67, which the assembler 
thinks is a real number. This problemis shown in sample code supplied to 
Dave Ritchie by JLO in conjunction with the 64180 assembler. 

Signed off 01/14/88 in release Z02.10 
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Number: 5000241562 Product: USER DEF EMULATION 64274 



Page: 



122 
01.05 



One-line description: 

run until <addr> fails from reset when reset points to user code. 

Problem: 

If the reset vector points to user code, the command "run until 
<addr>" from a reset state may not work correctly. The expected 
result is that the emulator will start executing user code and 
when the address is found by the analyzer, a break into the monitor 
will occur. 

What may happen is that the emulator will break into the monitor 
as a result of the analysis break from the "run until <addr>" 
command. Following this, an "exit monitor" command is given and 
the emulator starts running user code again without an analyzer 
break pending. The condition that will cause this command to work 
incorrectly is that the "until" address must not be accessed 
within approximately 30 mS of the release from reset. 

The generic algorithm that the UDE software uses for a "run until 
<addr>" command is as follows: 

1) The analyzer is set up with the break condition for the until 
address and it is then started. 

2) The processor is released from reset. 

3) An ARE YOU THERE monitor command is executed by the host to 
determine Tf the emulator is running in the monitor or running 
user code. 

4) If in the monitor, an EXIT monitor command is given. No test 

is made to determine if the break condition occurred to get into 
the monitor. 

If running user code, nothing is done. 

The incorrect behaviour is caused by step 4. Since there is no 
test to determine if the analyzer break caused entry into the 
monitor, the emulation software assumes that it must exit to user 
code so it issues the EXIT command when it should not. 

Temporary solution: 

A very reliable and easy to use workaround can be set up with a 
command file. In a command file called RU (for "run until"], 
put the following instructions. 

&PARMS ADDRESS 

trace before &ADDRESS break_on trigger 

run 



- -S 
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This command file performs exactly the same function as 
"run until <address>". It is invoked by typing 

RU xxxx 

where xxxx is the "until" address. 

Signed off 01/14/88 in release Z01.06 



Number: D200043828 Product: USER DEF EMULATION 64274 

One-line description: 

Bati display of trace data with 8-bit UDE 



)1.04 



Problem: 

With 8-bit UDE emulators, the trace, when displayed, gives the wrong 
data at odd addresses. What is seen in the trace is the same data in 
the odd address as was captured for the preceeding even address. Note 
that this problem is only with version 1.04 of the UDE software, the 
previous version 2420 does not exhibit the problem. 

Temporary solution: 

Changing the UDE Configuration file parameter M OPCODE_SIZE" 
to WORD will partially solve this problem. Changing the 
parameter to WORD, should allow the internal analyzer to 
display each data field, however, the data will be visually 
offset on the HP64000 display. Changing the "0PC0DE_SI2E" 
to equal WORD may adversely affect the inverse assembly of 
opcodes during single-stepping. 

Signed off 01/14/88 in release Z01.06 

Number: D200046623 Product: USER DEF EMULATION 64274 01.04 

One-line description: 

modify memory starting at odd addresses does not always work 

Signed off 01/14/88 in release 401.06 
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Number: 1650036525 Product: USER INTERFACE 
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300 64808S004 



124 
01.20 



- -S 



One- line description: 

Pmon flags a syntax error when attempting to append files 

Problem: 

pmon flags a syntax error for 

cat file >> file2 

But this a valid command and necessary to append i. e. a reloc file 
to a library. 

Temporary solution: 
Workaround: 

Use 

!cat file >> file2 

In this case however the pmon softkeys can't be used. 

Signed off 01/14/88 in release Z02.10 

Number: 1650038521 Product: USER INTERFACE 300 64808S004 02.00 

Keywords: MENUS 

One-line description: 

Pmon command completion via shell variables not working correctly 

Problem: 

Pmon generates collision errors in command completion between the 
external shell variables (whether set externally or by internal default) 
and the "default" pmon commands when they are the same. 

The problem appears with all commands controlled by external shell 
variables. 

Example: PM0N_C0MPILE not set, default pmon compile is "comp". If the 
user types co<tab>, pmon should complete to "comp". However, the error 
ERROR: possible tokens: comp, comp is generated. 

Signed off 01/14/88 in release Z02.10 



Number: D200077495 Product: USER INTERFACE 



300 64808S004 



01.20 



One-line description: 

User softkey display should be erased after shell escape. 

Problem: 

Display needs to be cleaned up when executing certain commands. 

In one case the softkeys need to be erased before going on. 

Signed off 01/14/88 in release Z02.10 



- -S 
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Number: "D200080135 Product: USER INTERFACE 



300 64808S004 



01.20 



One-line description: 

pwd truncates the /net/system portion of the path when RFA'ed to system. 

Problem: 

When using the HP 64000-UX products and netunaming across the LAN 
to another system, such as a compile server, the HP-UX command 
"pwd" which is used by the HP64000-UX product to tell what the 
local directory is, truncates the "/net/system" part of the path. 

This is a HP-UX operating system defect. It is not a defect in 

the HP 64000-UX application software. As soon as this defect is 

fixed in HP-UX, it will work correctly when using the HP 64000-UX 
applications. 

Signed off 01/14/88 in release Z02.10 



Number: D200080721 Product: USER INTERFACE 300 64808S004 



01.20 



One-line description: 

Pmon command completion intermittantly fails after completion error. 

Problem: 

Pmon evidently sets a flag on a command completion error which 
inhibits further errors on the same completion. Once the user 
types more characters and/or starts a new command, the flag should 
be reset such that new completion requests will be processed. 

Unfortunately, the flag is not consistently reset, so command 
completions after a completion error will intermittantly have 
no effect. 

Temporary solution: 

Use softkeys or, when command completion fails with no message of 
any kind, add more characters of command and try again. Most 
errors occur only at the one or two character level. 

Signed off 01/14/88 in release Z02.10 



Number: D200081141 Product: USER INTERFACE 300 64808S004 

One-line description: 

Command search algorithm should match the softkey package. 

Problem: 

Pmon will not properly execute a command file which is not 

in the current directory. If the command file is in the search 

path specified in the PATH variable, a shell is forked to execute 

the command file. The shell will refuse to execute the command 

file, presumably since pmon command files are not executable. 

Temporary solution: 

Use only command files which are in the current directory. 

Signed off 01/14/88 in release Z02.10 



01.20 
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Number: 5000170654 Product: Z80/NSC800 C 64824 01.03 

One-line description: 
Error using switch (*x++). 

Problem: 

The following program hangs during complation on the 64100 and flags an 
error on the 9000/500 hosted compiler. The 64100 displays "STATUS: comp 
iling C/Z80 in pass 2 Line #8, Errors=0". The error message from the 90 
00/500 is "line #8 -- pass 2 error #1006, 1006: Compiler Error. Contact 
Hewlett Packard. The program is as follows: 

"C" 

-Z80" 

/* program with switch problem */ 

main( ) 

{ 

char *chrptr,*chrptr2; 

*chrptr='a' ; 

switch (*chrptr++) { 

case 'a' : 

*chrptr='z' ; 

case 'b' : 

*chrptr='y' ; 

} 
} 

Temporary solution: 

The work around is to break the switch(*chrptr++) into two statements. 

The first is switch(*chrptr) and then after the switch statements do a 

*chrptr++. 



Signed off 01/14/88 in release Z02.10 
Number: 5000172825 Product: Z80/NSC800 C 



64824 



01.03 



One-line description: 

RETI is not generated when exiting an interrupt procedure. 

Problem: 

When using $INTERRUPT 0N$ the compiler does not generate the RETI 
instruction of the Z80 microprocessor. This is crucial when designing 
with such Z80 peripheral chips as the Toshiba Z84C30 Counter/Timer 
because the chip expects to see this instruction inorder to terminate 
its interrupt cycle. If the compiler is going to push all of the 
registers when using $INTERRUPT 0N$ then why not use the correct 
instruction when returning from the interrupt. One other point to be 
made is that the Z80 emulator 64253A takes into consideration this 
peripheral requirement when emulating out of emulation memory by 
enabling output buffers during emulation memory read cycles. 

Signed off 01/14/88 in release Z02.10 



SRB detail reports as of 09/01/88 
Number: 5000173278 Product: Z80/NSC800 C 
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One-line description: 

Array is being placed in the PROG section rather than data. 

Problem: 

Compiler puts array that should be in DATA section in PROG section 

Example: 

"C" 

"Z80" 

char array [12]; 

The above code when compiled creates an array of twelve bytes that will 
reside in the PROG section. This should be placed in the DATA section. 

Temporary solution: 

Generate an ASI"I_FILE and edit the ASMProcessor file to place 

the array under the DATA counter. 

Signed off 01/14/88 in release Z02.10 



Number: 5000231605 Product: Z80/NSC800 C 



64824 



01.04 



One-line description: 

+■ operator does not work for pointers to structures. 

Problem: 

Bad code generated when plus equals, times equals or divide equals (+=, 

*=, /= ) with pointers to structure elements are used. Example: 

"C" 

"Z80" 

$SEPARATE 0N$ 

struct fb { int i; int size; } x, y; 

main( ) { 

struct fb *a,*b; 

a = &x; 

b - &y; 

b -> size =3; 

a -> size =4; 

if( b !- a ) /* removing this line eliminates the problem */ 

a -> size += b -> size; /* wrong value stored in a-> size */ 
} 

The result of a += is actually a->size = &a->size + b->size 

Temporary solution: 

Expand the expression as follows: 

a->size = a->size + b->size; 

Signed off 01/14/88 in release Z02.10 
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Number: 5000233866 Product: Z80/NSC800 C 



64824 
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01.04 



One-line description: 

ZDconvert library module has two errors in the ZDdwordtoword routine. 

Problem: 

The ZDconvert module contains two errors in the ZDsdwordtoword con- 
version utility. 
These errors cause two problems: 

First, if the data to be converted is located at an adress above or 
equal to 8000H the routine generates an overflow error trap, although 
there actually is no overflow. 

Second, if the data to be converted is negative, the stack gets 
misalligned, which will cause unpredictable results. 



The problem is restricted to the "debug" conversion routine, 
will only occur if $DEBUG 0N$ is set in the source program. 

See the corrected Library Routine below for details: 



i.e. it 
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Temporary solution: 

No temporary solution, however you can turn $DEBUG 0FF$. 

Signed off 01/14/88 in release Z02.10 



Number: D200038778 Product: Z80/NSC800 C 



64824 



01.01 



One-line description: 

Incorrect transfer address when linking 9 or more files. 

Problem: 

I have files submitted by a customer which have the following problem. 
If you compile and assemble these files (most are C programs, a couple 
are assembly code) on the vax they will not link properly. What happens 
is the linker reports transfer address at loc XXXX defined by Zlibrary 
The address it reports is different than the address of the ENTRY label 
and in fact is outside of the module Zlibrary altogether. The customer 
said he had this problem when he linked eight or more files of any size. 
I cannot duplicate this with files I create, but, I can duplicate the 
problem with the files he sent me. Incidently, if the files are comp- 
iled on the 64000 and uploaded (relocs uploaded) they will link success- 



^usaworaiowora 
CALL 


Zsave address 


tuny. 

Temporary solution: 




PUSH 


AF 


Compile the files or 


the 64000 and upload the relocatables to the VAX. 


PUSH 


DE 


The 64000 generated 


reloc's will link successfully. 


LD 


E,[HL] 






INC 


HL 


Signed off 01/14/88 


in release Z02. 10 


LD 


D,[HL] 
;rf low 






* check for ov 


Number: D200071373 


Product: Z80/NSC800 C 64824 01.03 


LD 


A,H ! ERROR 1 ! should be LD A, [HL] 






OR 


A 


One-line descriptior 


: 


JP 


M.NEG DWORD 


INT Multiplication c 


f short by negative constant with SH0RT_ARITH. 


INC 


HL 


Problem: 








When the compiler directive $SH0RT ARITH 0N$ is in effect 






multiplication of byte sized quantities by negative constants will 


RET 




produce code that extends the byte to int size and then preforms an 


NEG DWORD INC 


HL 


int size multiplication operation. The following code illustrates: 


LD 


A,[HL] 






INC 


HL 


$SHORT_ARITH 0N$ 




AND 


[HL] 






EX 


DE.HL 


short s; 




CP 


-1 


unsigned short us; 




CALL NZ.Zoverflow 






RET 


! ERROR 2 ! 


main () 






POP DE 


{ 






POP AF 


if (s*-4) /* 


s is extended to int and a word mul performed */ 




must be included before the return 


error(); 






to be consistent with the POP's on 


if (us*0xfc) /* 


us is extended to int and a word mul performed */ 




entry of ZDsdwordtoword, because this 


error ( ) ; 






is the second return point of this 


} 






routine ! 










Signed off 01/14/88 


in release Z02. 10 




- -8 


- -8 
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One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 

Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SHORT_ARITH OFF$ 

short s; 

unsigned short us; 



ma in ( ) 



} 



if ( (s/usPOxff ff ) 

error) ) : 
if t(us%s) 0x007f) 

error! ) ; 
if (us==s) 

errort ) ; 
if (s!=us) 

errort ) : 
if (s<us) 

errort ) ; 
if (s>us) 

errort ) ; 



/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 
/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z02.10 



Number: D200075044 Product: Z80/NSC800 C 
One-line description: 



64824 



Problem: 

Z80 COMPILER GENERATING INCORRECT CODE FOR THE FOLLOWING PROGRAM. 



"C" 
"Z80" 

INT 



(*BGETVCO) 0; 



GETC(PARM) 
INT PARM; 

{ INT (*TEST)(); 

TEST = BGETVC(IO); 
RETURN ((TEST) (11, PARM) ): 



01.04 
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TEST CONTAINS AN ADDRESS WHICH POINTS TO A FUNCTION. WHEN IT IS 
ASSIGNED TO, THE CODE ASSIGNS THE CORRECT ADDR OF THE FUNCTION. 
HOWEVER, WHEN THE COMPILER GENERATES CODE TO CALL THE FUNCTION VIA 
TEST IT DOES NOT ACCESS TEST. INSTEAD IT ACCESSES A LOCATION TWO 
BYTES LOWER IN MEMORY. 

Signed off 01/14/88 in release Z02.10 



Number: D200077222 Product: Z80/NSC800 C 
Keywords: CODE GENERATOR 



64824 



01.04 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 

"C" 

"8088" 

main! ) 

{ 



} 



double xx ; 
xx = 2.0/3.0; 
xx = 2.0; 



xx is assigned the value 2.0 by both statements. 



This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 

Temporary solution: 

xx = 2.0/y; where y = 3.0; 

Signed off 01/14/88 in release Z02.10 



Number: D200079079 Product: Z80/NSC800 C 



64824 



01.04 



One-line description: 

+ = > -"i *". & /" may fail to auto vars with $RECURSIVE ON$ 

Problem: 
Text: 

+-, — . *', & /» may fail to auto vars with $RECURSIVE 0N$ 

SUBMITTER TEXT: 

Composite assignment operators may fail to automatic variables when 
$RECURSIVE 0N$ is in effect. This problem results from the compiler 
failing to keep track of how many bytes of parameters have been pushed 
onto the stack (and then popped off) for runtime library routines. 
The effect of this failure is an incorrect stack location being updated. 
The following program segment illustrates this problem. 

"C" 
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■•8085" 
$RECURSIVE 0N$ 

fund il, i2,doub) 
int il,i2; 
double doub; 
{ 

int answer; 

answer = 1; 

answer +■ i2*x; /* after this statement answer still is 1 */ 



V 



/* however il « i2 * x 



Signed off 01/14/88 in release Z02.10 

Number: D200080374 Product: Z80/NSC800 C 64824 01.04 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 

"C" 

"68000" 

unsigned int a; 

main! ) 

{ 

a=0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 

Signed off 01/14/88 in release Z02.10 



Number: D200081471 Product: Z80/NSC800 C 

One-line description: 

MOD operation returning the wrong value. 

Problem: 

The MOD operator is returning the wrong value. 



64824 



01.04 
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"BZ80" 

PROGRAM TEST; 
SEXTENSIONS 0N$ 
$GL0BVAR 0N$ 
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VAR 11,12,13: 
BEGIN 



INTEGER; 



II 
12 
13 



= 5280; 
• 1000; 
- II MOD 12; 



END. 



The result of the mod operation is 4280 decimal. 

Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release 402.10 



SRB detail reports as of 09/01/88 
Number: 5000226605 Product: Z80/NSC800 C 
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300 64824S004 01.20 



One-line description: 

Double word divide library returning incorrect result. 

Problem: 

Zsdworddiv calculates incorrectly. The result calculated becomes 1, 

if it was incorrect. 

Zsdworddiv is correct on 64000. This is the problem on 9000/300. 

The example is as followes, 



"C" 
"Z80" 



long a,b,ldiv; 

main( ) 

{ 

a=70000; 

b-150; 

ldiv = a/b; <■ 
} 



ldiv must be 01D2H but it is 1 



Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z02.10 



- -8 
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Number: 1650011585 Product: Z80/NSC800PASCAL 

Keywords: PASS 2 



64823 



Page: 136 

01.01 



One-line description: 

Incorrect code generated when set elements are passed as parameters. 

Problem: 

Incorrect code is generated when sets are passed as parameters. 
The stack pointer is manipulated so that the program "goes in the 
weeds" after the call to the procedure. The following code is 
an example: 

"processor name" 
SSEPARATE 0N$ 
SEXTENSIONS 0N$ 
TYPE 

Letters » (a,b,c,d,e, f ,g,h, i, j ,k, l,m,n,o, r) ; 

Set_of_Letters = SET OF Letters; 
SGLOBPROC 0N$ 

PROCEDURE Letters_Pas(Received:Set_of_Letters) :EXTERNAL; 
PROCEDURE Init_Set; 
BEGIN 

Letters_Pas( [] ) ; (*Code generates an extra INC SP after the 
END; ~ call to Letters_Pas*) 

$GLOBPROC 0FF$ 

Temporary solution: 

Any set size which is not equal to 3 bytes will work correctly. 

Signed off 01/14/88 in release Z01.90 



Number: 5000161000 Product: Z80/NSC800PASCAL 



64823 



01.03 



One-line description: 

Unbelieveable amount of library code linked for no-line program. 

Problem: 

The following no-line program yields a 4000 byte absolute file 

when linked with Zlibrary and Zreallib. 

"BZ80" ; 

PROGRAM L0TS_0F_C0DE; 
PROCEDURE REAL_ADD; EXTERNAL; 
BEGIN 
END. 

Several modules that seem to be unnecessary (e.g. REAL_ADD,REAL_ATAN, 
REALJ1UL) are loaded. Since the address space of the Z80 is only 
64K, the libraries should be written in such a way to minimize the 
code loaded. 

Signed off 01/14/88 in release Z01.90 



SRB detail reports as of 09/01/88 

Number: 5000161034 Product: Z80/NSC800PASCAL 



64823 
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01.03 



One-line description: 

Libraries reference procedures not actually needed. 

Problem: 

The following code requires the lib, reallib, piolib, and simlib 

to be linked so that no linker errors are generated. 

•BZ80" 

PROGRAM SIM; 
VAR 

REAL_S : STRING; 

X : REAL; 

P,Q : INTEGER; 
BEGIN 

P := 1; 

STRWRI TE ( RE AL_S , P , Q , X ) ; 

STRREAD ( REAL_S , P , Q , X ) ; 
END. 

Linking all of the libraries causes the absolute file to be 
17000 bytes long. 

Signed off 01/14/88 in release Z01.90 



Number: 5000163287 Product: Z80/NSC800PASCAL 



64823 



01.04 



One-line description: 

Code generated by compiler increased 12% with latest version. 

Problem: 

Latest revision of the compiler generates approximately 12% more 
code then the previous revision did, according to this customer. 
The following example was submitted showing a piece of code that 
generated 2 lines of code with the previous version, and now 
generates 7 lines of code with the most recent version. 

"BZ80" 

PROGRAM DUMMY; 
CONST 

C_S = 32; 
TVPE 
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Signed off 01/14/88 in release Z01.90 
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Number: 5000182014 Product: Z80/NSC800PASCAL 



64823 



01.03 



One-line description: 

FOR statement with SIGNED_BYTE produces incorrect code. 

Problem: 

Bad code generated when FOR statement requires a signed byte 

mod library call. Example: 

"BZ80" 

SEXTENSIONS 0N$ 

VAR 

A,B:BYTE; 
BEGIN 

FOR A:=(B MOD 64) TO 100 DO 

END. 

The problem is that a temporary storage location is set up for the 
FOR loop counter, but after the initial value of the mod is 
calculated, register A is loaded from this location temporary storage 
location instead of being stored there. 

Temporary solution: 

Use UNSIGNED_8 instead of BYTE, or declare a temporary variable 
to hold the result of the mod operation. 

Signed off 01/14/88 in release Z01.90 



Number: 5000186742 Product: Z80/NSC800PASCAL 
Keywords: ADDR 



64823 



01.03 



One-line description: 

ADDR(x) generates incorrect code is x is of type BYTE. 

Problem: 

Incorrect code generated when using ADDR function if taking the 

address of a local variable of type "BYTE". EXAMPLE: 

"BZ80" 

PROGRAM TEST; 

SEXTENSIONS 0N$ 



ri = ntn-UKU 

C : SIGNED 16; 




(fiCLUKblVb UW» 


END; 




PROCEDURE RUN; 


VAR 




VAR 


LED : PI; 




ONE: BYTE; 

ONE POINTER: "BYTE; 


PROCEDURE A; 




BEGIN 


BEGIN 




ONE POINTER: -ADDR (ONE); 


LED.C := C S; (*Generates 7 lines of code, 


used to generate 2*) 


END; 


END; 




An incorrect value is written to ONE POINTER 


BEGIN 






LED.C := C S; 




Temporary solution: 


END. 




Use $RECURSIVE OFF$, or declare 0NE_P0INTER outside the procedure, 


- -8 




- -8 
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or use type INTEGER instead of BYTE. 


Signed off 01/14/88 in release Z01.90 


Signed off 01/14/88 in release Z01.90 


Number: D200063875 Product: Z80/NSC800PASCAL 64823 01.03 


Number: 5000190629 Product: Z80/N3C800PASCAL 64823 01.04 


One-line description: 




functional type change of a constant into multi-byte structure gen's err 


One-line description: 




Bad code generated when CASE expression involves addition of two bytes. 


Problem: 




Functional type casting of a constant into a multi-byte structure 


Problem: 


generates bad data. 


Bad code generated when CASE statement expression is the addition 




of two BYTEs: 


"processor" 


"BZ80" 




$EXTENSIONS+$ 


PROGRAM BAD_DATA; 


PROGRAM BUG PROG; 




PROCEDURE BUG; 


TYPE EVENT = RECORD 


VAR 


A : BYTE; 


A,B,C:BYTE; 


B : BYTE; 


BEGIN 


C : INTEGER; 


A:=l; B:=2; 


D : BYTE; 


CASE A+B OF 


END; 





C 


=0; 




1 


C 


=i; 


VAR EVENT 1 : EVENT; 


2 


C 


=2; 




3 


C 


=3; OTHERWISE C:=100; END END; 






PROCEDURE GENERATOR)); 




BEGIN 


Temporary solution: 


EVENT1 := EVENT(O); { THIS ASSIGNMENT RESULTS IN BAD DATA } 


1. Store the result of A+B in a temporary value, then CASE on that 


END; 


temporary value. 




2. Use INTEGER (A+B) 


BEGIN 


3. Declare A and B as type INTEGER 


END. 


Signed off 01/ 


14/ 


38 in release Z01.90 


Temporary solution: 









No temporary solution at this time. 


Number: 5000217927 Product: Z80/NSC800PASCAL 


64823 


01.04 


Signed off 01/14/88 in release Z01.90 


One-line description: 








Signed_32 divide returns wrong result. 


Number: D200066761 Product: Z80/NSC800PASCAL 64823 01.03 


Problem: 






One-line description: 


The library Zsdworddiv improperly handles some 


signed 32 bit 




Code generated by compiler increased 12% with latest version. 


divisions. Example: 








"BZ80" 






Problem: 


PROGRAM DIVIDE; 






Latest revision of the compiler generates approximately 12% more 


VAR 






code then the previous revision did, according to this customer. 


B1,B2,B3:SIGNED 32 






The following example was submitted showing a piece of code that 


BEGIN 






generated 2 lines of code with the previous version, and now 


Bl:=362700; 






generates 7 lines of code with the most recent version. 


B2:=2000; 








B3:=B1/B2; {the result returned is one} 






"BZ80" 


END 






PROGRAM DUMMY; 
CONST 

C S = 32; 


Temporary solution: 






TYPE 


No temporary solution at this time. 






PI = RECORD 

C : SIGNED_16; 


- -8 






- -8 
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END; 




VAR 


BEGIN { TEST1018B } 


LED : PI; 


L0CAL1018 := ; 




NEST1 ; 


PROCEDURE A; 


END ; { TEST1018B } 


BEGIN 




LED.C := C S; ('Generates 7 lines of code, used to generate 2*) 




END; 


Signed off 01/14/88 in release Z01.90 


BEGIN 


Number: D200071340 Product: Z80/NSC800PASCAL 64823 01.03 


LED.C := C S; 




END. 


One-line description: 




Certain variable accesses by nested procedures may not work 


Signed off 01/14/88 in release Z01.90 






Problem: 


Number: D200071332 Product: Z80/NSC800PASCAL 64823 01.03 


In certain situations where a local variable of one procedure is 




referenced by another procedure nested inside the first procedure, 


One-line description: 


the register loaded with the link may be walked on. The following 


Links not correctly established during calls of nested procedures. 


code illustrates the problem. 


Problem: 




Calls between procedures at different nesting levels may not correctly 


"PASCAL" 


establish links needed for referencing higher level variables. The 


"BZ80" 


following code illustrates the problem. 


$EXTENSIONS 0N$ 




$RECURSIVE 0N$ 


"PASCAL" 


PROGRAM BUG1018A; 


"BZ80" 




$EXTENSIONS 0N$ 


PROCEDURE LEVEL 1 ; 


$RECURSIVE 0N$ 


VAR 




LEV1_1, LEV1_2 : INTEGER ; 


PROGRAM BUG1018B; 






PROCEDURE LEVEL2 ; 


PROCEDURE TEST1018B; 


VAR 


VAR 


ARR1 : STRING ; 


LOCAL1018 : INTEGER ; 


INDEX : INTEGER ; 


PROCEDURE INC LOCAL ; 


BEGIN { LEVEL2 } 


BEGIN 


ARR1[INDEX] := CHR (LEVI 2 + 1) ; { access to LEVI 2 incorrect } 


LOCAL1018 := L0CAL1018 + 1; 


END ; { LEVEL2 } 


END ; 






BEGIN { LEVEL1 } 


PROCEDURE NEST1 ; 


LEVEL2 ; 


VAR 


END ; { LEVEL 1 } 


DUMMY 1 : INTEGER ; 





PROCEDURE NEST2 ; 
VAR 

DUMMY2 : INTEGER ; 
BEGIN { NEST2 } 

INC_LOCAL ; (* variable local is NOT correctly incremented *) 
END ; { NEST2 > 

BEGIN { NEST1 } 

INC_LOCAL ; (* variable local is correctly incremented *) 

NEST2 ; 
END ; { NEST1 } 

- -8 



Signed off 01/14/88 in release Z01.90 
Number: D200071365 Product: Z80/NSC800PASCAL 
Keywords: PASS 1 



64823 



01.03 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 



SRB detail reports as of 09/01/88 

the following code illustrates the problem. 



$EXTENSIONS 0N$ 
PROGRAM PTEST; 
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VAR 



S8 
U8 
S16 
U16 



SIGNEDJ3 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 



BEGIN 

U16 := UNSIGNED_16(S8); (* signed extension of S8 - correct *) 
U16 := UNSIGNED_8(S8) ; (* signed extension of S8 - incorrect 



S16 
S16 



END. 



SIGNED_16(U8): 
SIGNED_8(U8) ; 



(* unsigned extension of U8 - correct *) 
(* unsigned extention of U8 - incorrect *) 



Signed off 01/14/88 in release Z01.90 



Number: D200071423 Product: Z80/NSC800PASCAL 64823 

One-line description: 

Function Calls via pointer may fail 

Problem: 

Function calls via pointers may fail. The following code sample 

illustrates the problem: 



01.03 



typedef int (*PFI)(); 

extern int code_array[100] ; 

ma int ) 
{ 

(*((PFI)code_array)l (); 

LXI H,main01_0 

PUSH H 

LHLD code_array 

PUSH H 

RET 
mainOl 



/* code_array is actually a function */ 



/* this call fails to transfer 
control to code array */ 



/* the instruction should be 
LXI H,code_array */ 



} 

Temporary solution: 

typedef int (*PFI)(); 

PFI func_ptr; 

extern int code_array [100] ; /* code_array is actually a function */ 

mainl ) 
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{ 



} 



func_ptr = code_array; 

(*func_ptr) ( ) ; " /* call to code_array is correct */ 



Signed off 01/14/88 in release Z01.90 
Number: D200073031 Product: Z80/NSC800PASCAL 



64823 



01.03 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 

changes physical size), when it should generate a fatal error. It 

tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 

"PASCAL" PREPROCESS 
"6809" 

{ Test program to demonstrate Pascal language defect } 
{ Functional type change of constant to multi-byte variable } 
PROGRAM PTEST101; 
SEXTENSIONS 0N$ 
TYPE event = RECORD 

type : BYTE; 
qualifier: BYTE; 
msg : INTEGER; 
send_task: BYTE; 
END; 
VAR eventl: event; 
i: INTEGER; 
R: REAL; 

BEGIN 

{The following code is attempting to initialize} 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 
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eventl :- event(O); {This code is incorrect Pascal} 



{Correct Pascal using individual assignments} 

eventl. type:=0; 

event l.qualif ier:=0; 

eventl. msg: =0; 

eventl . send_task : =0 ; 
END . 



Signed off 01/14/88 in release Z01.90 



Number: D200076067 Product: Z80/NSC800PASCAL 



64823 



01.04 



One-line description: 

Unsigneci_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
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A : INTEGER; 
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BEGIN 



ST0PSECT0R := UNSIGNED_16(247) ; 

FOR SECTORNUM := UNSIGNED_16(0) TO ST0PSECT0R DO BEGIN 

A := 5; 
END; 
END. 

This works for values up to 8000H. 
Signed off 01/14/88 in release Z01.90 



Number: D200079301 Product: Z80/NSC800PASCAL 



64823 



01.04 



One-line description: 

Compiler may confuse similar parameters in different subroutines 



compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

SEXTENSIONS 0N$ 

PROGRAM DOLOOP; 


Problem: 

The Z80 & 8085 B Pascal compilers may confuse similar parameters in 
different (but nested) subroutines. The following program illustrates 
this problem. The problem stems from the compiler searching for a 
parameter in a register. It finds one with the correct attributes 
(position, size, indirects, data type, etc), but it is unfortunately 
not from the correct subroutine. 


VAR SECTORNUM, STOPSECTOR : UNSIGNED 8; 
A : INTEGER; 

BEGIN 

STOPSECTOR := UNSIGNED_8(247) ; 


"PASCAL" PREPROCESS 
"BZ80" 

SEXTENSIONS 0N$ 
$SEPARATE 0N$ 
SRECURSIVE 0N$ 


FOR SECTORNUM := UNSIGNED_8(0 ) TO STOPSECTOR DO BEGIN 


PROGRAM PTEST104; 


A :- 5; 


PROCEDURE TEST1018; { Test problems in Pascal Scoped_ACCESSES; } 


END; 
END. 


PROCEDURE Levell(llpl,llp2:BYTE); 
VAR 

llvl,llv2: BYTE; 


Temporary solution: 

USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 


PROCEDURE Level2 ( 12pl , 12p2 : BYTE ) ; 
VAR 

12vl,12v2: BYTE; 


"PROCESSOR" 
$EXTENSIONS 0N$ 
PROGRAM DOLOOP; 


BEGIN {Level2} 

12p2:=llv2; 

llvl:=llp2; { ERROR llvl gets the value of 12p2 rather than llpl. } 
END; { The value of 12p2 was in a register from the } 
{ previous assignment. 


VAR SECTORNUM, STOPSECTOR : UNSIGNED_16; 


BEGIN {Levell} 


- -8 


- -8 
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END; 




Number: 5000224204 Product: Z80/NSC800PASCAL VAX 64823S003 


01.70 


BEGIN {TEST1018} 
END; 




One-line description: 

Nested external procedure call causes bad code to be generated. 




Temporary solution: 
No temporary solution. 

Signed off 01/14/88 in release 301.90 




Problem: 

Bad code is generated when a procedure which is declared external 

within a second procedure that passes parameter(s) to a third. 

Example: 

"BZ80" PREPROCESS 
PROGRAM HAROLD; 
$EXTENSIONS+$ 
VAR B:BYTE; 
PROCEDURE ERROR ; 

PROCEDURE CLR PRTB ( MASK : BYTE ) ; EXTERNAL : 
BEGIN 

CLR P0RTB( B ) ; 
END; 














Temporary solution: 

WORKAROUND: declare PROCEDURE CLR_PORTB (MASK : BYTE) ; EXTERNAL ; 

in the outer scope of the module, not inside the procedure. 








Signed off 01/14/88 in release Z01.90 
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Number: D200076760 Product: Z8000 C 



64820 
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01.06 



One-line description: 

Array is being placed in the PROG section rather than data. 

Problem: 

Compiler puts array that should be in DATA section in PROG section 

Example: 

"C" 

"Z80" 

char array [12]; 

The above code when compiled creates an array of twelve bytes that will 
reside in the PROG section. This should be placed in the DATA section. 

Temporary solution: 

Generate an ASM_FILE and edit the ASMProcessor file to place 

the array under the DATA counter. 

Signed off 01/14/88 in release Z02.10 



Number: D200077107 Product: Z8000 C 
Keywords: CODE GENERATOR 



64820 



01.06 



One-line description: 

Floating point division of 2 constants generates incorrect result 

Problem: 

Compiler generates incorrect code for evaluation of double division: 
"C" 

"8088" 
main( ) 
{ 

double xx ; 

xx = 2.0/3.0; 

xx = 2.0; 
} 
xx is assigned the value 2.0 by both statements. 



This problem also occurs with other variable types such 
as float, long. Any constant divided by a constant will 
generate this error. 



Temporary solution: 

xx = 2.0/y; where y 



3.0; 



Signed off 01/14/88 in release Z02.10 



Number: D200079137 Product: Z8000 C 
Keywords: PASS 1 



64820 



01.03 



One-line description: 

DIV, MOD and COMParisons may do unsigned estend of signed values 
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Problem: 

Conditionals that employ div, mod, or comparison operations may not 
correctly extend signed short values to int size if the other operand 
is an unsigned short or char. For example, in the following code s 
is extended as if it were declared an unsigned short. 



$SH0RT_ARITH 0FF$ 

short s; 

unsigned short us; 

main( ) 
{ 

if ((s/usPOxffff) 

error ( ) : 
if ((us'/.s) 0x007f) 

error( ) ; 
if (us"s) 

error ( ) : 
if (s!«us) 

error ( ) ; 
if (s<us) 

error ( ) ; 
if (s>us) 

error ( ) ; 



} 



/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 

/* both s and us get unsigned extend */ 



Signed off 01/14/88 in release Z02.10 



Number: D200080341 Product: Z8000 C 64820 01.06 

One-line description: 

Warning message text is incorrect. 

Problem: 

68000 C compiler, Just updated to 2.07. 

Warning 521: Unsigned integer to real conversion treated as signed. 
Is incorrect. 

The wording should imply that the conversion should be going the other w 
ay, from real to unsigned integer. 

To get the error: 

"C" 

"68000" 

unsigned int a; 

main!) 

{ 

a-0.0; 

} 

NOTE: this error message is not in the manuals. 

Temporary solution: 

If you do not want to see this message you may specify 

$WARN 0FF$. This will turn off all warning messages. 

- -8 
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-8 
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Number: D200063834 Product: Z8000 PASCAL 



Page: 



64816 



152 
01.11 



One-line description: 

functional type change of a constant into multi-byte structure gen's err 

Problem: 

Functional type casting of a constant into a multi-byte structure 

generates bad data. 

"processor" 

PROGRAM BAD_DATA; 

TYPE EVENT = RECORD 



A 


BYTE; 


B 


BYTE; 


C 


INTEGER; 


D 


BYTE; 


END; 





VAR EVENT 1 



EVENT ; 



PROCEDURE GENERATOR ( ) ; 
BEGIN 

EVENT1 := EVENT (0); { THIS ASSIGNMENT RESULTS IN BAD DATA } 
END; 

BEGIN 
END. 

Temporary solution: 

No temporary solution at this time. 

Signed off 01/14/88 in release Z01.90 



Number: D200076026 Product: Z8000 PASCAL 



64816 



01.12 



One-line description: 

Unsigned_8 treated as signed value in FOR loop test. 

Problem: 

Assigning a constant to an unsigned_8 variable whose upper bit is set 
causes problems. Specifically, when the unsigned_8 var is used later 
it is treated as a signed value. In the example below, an unsigned_8 
is assigned 247 decimal at the top of a FOR loop. When the compiler 
compares it is does a byte compare and therefore interprets the 
unsigned_8 as a signed quantity. 

"processor" 

SEXTENSIONS 0N$ 

PROGRAM DOLOOP; 



VAR 



SECTORNUM , STOPSECTOR 
A 



UNSIGNED_8; 
INTEGER; 
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BEGIN 

STOPSECTOR :- UNSIGNED_8(247); 

FOR SECTORNUM := UNSIGNED_8(0) TO STOPSECTOR DO BEGIN 

A := 5; 

END; 

END. 

Temporary solution: 

USE AN UNSIGNED_16 FOR THE CONTROLLING VAR. 

"PROCESSOR" 
SEXTENSIONS ON$ 
PROGRAM DOLOOP; 
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VAR 



BEGIN 



SECTORNUM , STOPSECTOR 
A 



UNSIGNED_16; 
INTEGER: 



STOPSECTOR := UNSIGNED_16(247); 

FOR SECTORNUM : =■ UNSIGNED_16(0 ) TO STOPSECTOR DO BEGIN 

A :« 5; 
END; 
END. 

This works for values up to 8000H. 
Signed off 01/14/88 in release Z01.90 



Number: D200079210 Product: Z8000 PASCAL 



64816 



01.12 



One-line description: 

Pascal does not report error for assignment of constant to structure 

Problem: 

The Pascal/64000 compiler fails to report an error when using 
the functional type change operator to attempt to assign an 
immediate constant to a multi-byte structure. 

Since the Pascal/64000 compiler does not support structured constants, 
there is no meaningful way to assign a constant to a structure. 
Each element must be assigned individually. 

The Pascal/64000 compiler does report an error 505 (Warning: type 
changes physical size), when it should generate a fatal error. It 

- -8 



SRB detail reports as of 09/01/88 



Page: 154 



tries to generate code for the illegal statement which will not 

produce the results expected by the user. 

The compiler should produce fatal Error #451: Structured constants not 

implemented. 

Here is a simple example and the workaround by explicit individual 
assignment statements. 

"PASCAL" PREPR0CESS 
"6809" 

{ Test program to demonstrate Pascal language defect > 
{ Functional type change of constant to multi-byte variable } 
PROGRAM PTEST101; 
SEXTENSIONS 0N$ 
TYPE event = RECORD 

type : BYTE; 
qualifier: BYTE; 
msg : INTEGER; 
send_task: BYTE; 
END; 
VAR event 1: event; 
i: INTEGER; 
R: REAL; 

BEGIN 

{The following code is attempting to initialize} 

{ the multibyte record event to zeros. } 

{It should be interpreted as a Pass 1 error } 

{ Error #451: Structured constants not implemented} 

{ The code produced will be processor dependent } 

eventl := event(O); {This code is incorrect Pascal} 



{Correct Pascal using individual assignments} 

eventl. type: =0; 

event l.qual if ier:=0; 

eventl. msg: =0; 

event 1 . send_task : =0 ; 
END . 



Signed off 01/14/88 in release Z01.90 



Number: D200079277 Product: Z8000 PASCAL 
Keywords: PASS 1 



64816 



01.12 



One-line description: 

Functional type changes not always evaluated correctly 

Problem: 

Some functional type changes are not correctly evaluated. For example, 

the following code illustrates the problem. 
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$EXTENSIONS ON$ 
PROGRAM PTEST; 
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VAR 



S8 
U8 
S16 
U16 



SIGNED_8 ; 
UNSIGNED_8 ; 
SIGNED_16 ; 
UNSIGNED 16 



BEGIN 

U16 := UNSIGNED_16(S8 
U16 := UNSIGNED_8(S8) 



); (♦ 



signed extension of S8 - correct *) 
signed extension of S8 - incorrect 



S16 

S16 



END. 



SIGNED_16(U8) ; 
SIGNED_8(U8) ; 



unsigned extension of U8 
unsigned extention of U8 



correct *) 
incorrect *) 



Signed off 01/14/88 in release Z01.90 
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Number: 5000137869 Product: Z8002 EMULATION 64233 

One-line description: 

Monitor displays wrong value for R15 and SSTK 

Problem: 

When displaying register contents, the value shown for 
R15 and SSTK is 6 (six) less than it should be. This 
is a result of the way the monitor is entered. 



Temporary solution: 

Modify the emulation monitor as follows: 
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01.07 



440 LD 
NEW INC 

441 LD 
NEW INC 



M0NR14L,R14 
R15,#6 
M0NR15L.R15 
M0NSSTKL,#6 



709 ************************* 
NEW DEC M0NSSTKL,#6 

Signed off 01/14/88 in release Z02.01 



Number: 5000151431 Product: Z8002 EMULATION 



64233 



02.00 



One-line description: 

User interrupts are not serviced for 17ms after analysis generated break 

Problem: 

Starting with revision 1.07 of the emulation operating software, the 
STOP line is asserted over a 17ms period with a duty cylce of 520us 
asserted, followed by 40us of time with the STOP line disasserted. 
Version 1.06 of the emulation software similarly asserted the STOP line 
but for only approximately 2.3ms with a 50% duty cyle of 40us on, 
followed by 40us off. The problem comes with the fact that the cpu 
will suspend all operations while the STOP line is asserted. So with 
version 1.07 of the software, there is a period of 17ms during which 
the cpu will only be active for 1.2ms If user interrupts occur 
more often than every 17ms and the interrupt service routine takes 
more than 1.2ms to complete, then user interrupts will be missed. 
NOTE: This problem occurs only after an analysis generated break. 
Therefore you may only see the problem after "trace break_on 
trigger/measurment_complete" , or "run until <state>". 

Version 1.07 is essentially equivalent to version 2.00 with 
regard to this problem. 

Temporary solution: 

Contact your HP representative if you encounter this problem. 

He should be able to get you a copy of the software that 

solves this problem until the new revision of software is 

available. 

Signed off 01/14/88 in release Z02.01 
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Number: D200071415 Product: Z8002 EMULATION 64233 02.00 

One-line description: 

Can't find symbols loaded with more address bits than specified. 

Problem: 

If the user links his code with more significant address bits 
than the number specified in the emulation configuration, the 
emulator will be unable to access the symbols, and the monitor 
may not function properly. 

Signed off 01/14/88 in release Z02.01 
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